在Golang项目规模扩大之后，单一模块往往难以支撑复杂的业务边界，这时候就需要把系统拆成多个模块分别维护。管理多模块项目核心要解决依赖版本、本地联调和统一构建的问题。
使用独立的go.mod管理多个模块
最常见的方式是为每个子项目创建独立的go.mod文件，它们各自拥有自己的模块路径和版本。比如仓库结构如下：
- service-user/
- service-order/
- pkg-common/
每个目录执行go mod init即可成为独立模块。模块之间发布到仓库后通过版本号引用。
// 在 service-order 中引用已发布的 pkg-common // go.mod 内容示例 module github.com/demo/service-order go 1.21 require github.com/demo/pkg-common v1.0.2
用Go Workspaces进行本地多模块联调
Go 1.18引入的workspace能让你在本地同时修改多个模块而不必先发布版本。在项目根目录执行命令生成go.work：
go work init ./service-user ./service-order ./pkg-common
之后在任意模块中修改pkg-common的代码，其他模块会直接引用本地源码。开发完成后可删除go.work或忽略提交。
通过replace指向本地路径
如果不使用workspace，也可以在模块的go.mod中用replace临时替换远程依赖为本地路径：
// service-order/go.mod replace github.com/demo/pkg-common => ../pkg-common
这种方式适合小团队快速验证，但容易忘记在发布前去掉replace导致构建错误。
方法对比
| 方式 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 独立go.mod | 模块已稳定并独立发布 | 版本清晰、解耦彻底 | 本地联调需发版 |
| Go Workspaces | 多模块并行开发 | 无需发版、官方支持 | 仅本地生效 |
| replace指令 | 临时本地调试 | 配置简单 | 易误提交 |
实践建议
团队日常开发推荐用Go Workspaces统一管理多模块，发布时确保每个模块版本号遵循语义化规范。对于基础库类模块，稳定后走独立go.mod发布流程，业务模块通过require固定版本，既能灵活开发也能保证生产构建可重现。