大型Python项目拆分应围绕可维护性、可测试性、团队协作和部署灵活性重构，按业务领域（如订单、商品）划分独立模块，封装完整逻辑并暴露明确API；模块间禁止直接访问内部实现，须通过接口或事件通信；稳定通用能力应提取为语义化版本的独立shared/core库。
大型Python项目拆分不是简单地把代码按文件夹切开，而是围绕可维护性、可测试性、团队协作和部署灵活性来重构代码结构。核心是识别业务边界、隔离变化点、明确模块职责，并通过清晰的接口约定降低耦合。
按领域/功能边界划分模块
避免按技术分层（如models/views/utils）先行，优先从实际业务场景出发。例如电商系统中，“订单”“商品”“用户”“支付”应各自为独立模块，每个模块内封装完整的数据模型、业务逻辑、校验规则和对外接口。
- 每个模块对应一个包（含__init__.py），对外只暴露明确的API入口（如order.create()、product.search()）
- 模块间禁止直接跨包访问内部实现（如from user.internal_auth import TokenValidator），必须通过公开接口或事件通信
- 使用pyproject.toml或setup.py将模块注册为可安装的子包，便于本地开发与CI中独立测试
提取稳定通用能力为共享库
当多个业务模块重复出现相同逻辑（如日期格式化、HTTP客户端封装、异步任务基类），说明这部分已具备稳定性与复用价值，应剥离为独立的shared或core库。
- 该库不依赖任何业务模块，只引入基础依赖（如requests、pydantic）
- 版本需严格语义化，重大变更必须发新版，业务模块按需声明兼容版本（如shared >= 2.1.0, ）
- 推荐用poetry或pip-tools管理多模块依赖，避免隐式传递依赖污染
用接口契约+依赖注入解耦模块协作
模块之间不硬编码调用，而是定义抽象接口（Protocol或ABC），运行时由配置或容器注入具体实现。例如“通知模块”不直接调用邮件服务，而是依赖Notifier接口，测试时可注入MockNotifier，生产环境切换为SMSNotifier或EmailNotifier。
- 接口定义放在被调用方模块的interfaces.py中，调用方仅导入协议，不感知实现位置
- 使用dataclasses或pydantic.BaseModel定义跨模块数据结构，避免dict嵌套传递导致的隐式契约
- 启动时统一初始化依赖图（可用dependency-injector或轻量级工厂函数），避免散落在各处的new操作
渐进式拆分：从单体中识别并迁移高内聚子域
不要一开始就重写整个架构。先静态分析代码调用关系（用pyan3、pydeps或IDE的依赖图），找出调用密集但外部引用少的代码簇，作为首个拆分目标。
- 新建模块，复制相关代码，修复import路径，补全类型提示和测试
- 在原单体中保留兼容层（Adapter），转发调用到新模块，逐步将上游引用切换过去
- 每次拆分后运行端到端测试+关键路径冒烟测试，确保行为不变
