go单体项目模块化核心是职责边界、显式依赖与接口设计，而非过早物理拆分；应先逻辑分层（domain/application/infrastructure等）、包级封装、接口+DI解耦，再按需渐进升级为多module。
在Go单体项目中拆分模块，核心不是物理切分代码目录，而是通过清晰的职责边界、显式的依赖关系和可独立演进的接口设计，让各部分具备“准模块化”能力。过早按业务域硬拆为多个go module，反而会增加版本管理与发布协同成本；更务实的做法是先做逻辑分层与内聚封装，再逐步解耦。
从包（package）开始划清职责边界
Go天然以包为最小复用单元。拆分第一步是审视现有main或cmd下堆积的代码，将功能归类到语义明确的包中：
- domain/：只放纯业务结构体、领域接口、核心校验逻辑，不依赖任何外部库（如database、http）
- application/：实现用例（Use Case），协调domain与infra，含Command/Query结构、DTO、应用服务
- infrastructure/：具体实现细节——数据库驱动、HTTP handler、缓存客户端、第三方API适配器
- interfaces/（或adapter/）：面向外部的入口，如API路由、CLI命令、消息消费者
关键原则：上层包可导入下层，但禁止反向依赖。用go list -f ‘{{.Deps}}’ ./… | grep …或工具如goda检查隐式循环引用。
用接口+依赖注入松解耦合
避免在application层直接调用infrastructure.mysql.UserRepo。改为定义repository.UserRepository接口，放在domain或application中，由infrastructure实现并注入：
- 在application包中声明：type UserRepository Interface { FindByID(id int) (*User, Error) }
- 在infrastructure/mysql中实现该接口
- 启动时（如cmd/main.go）用构造函数或Wire等DI工具注入具体实现
这样domain和application不感知数据库技术选型，测试时可轻松替换为内存Mock实现。
渐进式升级为多module（非必须）
当某个子模块（如支付引擎、搜索服务）确实需要独立发版、被其他项目复用，或团队协作需隔离权限时，再将其拆为独立go module：
- 新建仓库或子目录，初始化go mod init github.com/yourorg/payment
- 导出的接口和类型应稳定，避免频繁breaking change
- 主项目通过replace或require引入，而非直接复制代码
- 注意：跨module调用无法享受Go的编译期依赖检查（如未实现接口），需靠测试与CI保障
多数内部单体项目，保持单module + 清晰包结构已足够支撑2–3年演进。
配套机制让拆分落地有效
模块化不仅是代码组织，更是协作契约：
- 文档化边界：每个包的README.md写明职责、输入输出、不做什么
- 自动化验证：用golangci-lint配置goimports和dupl，配合自定义规则检查跨层调用
- 测试分层：domain层跑纯单元测试，application层用Mock infra测试流程，integration测试才连真实DB/API
- 发布节奏解耦：即使单module，也可按包粒度做Changelog分类、按需触发CI流水线阶段
基本上就这些。不复杂但容易忽略的是：拆分目标不是让目录变多，而是让人看一眼就知道“这部分改了会影响谁”。