Go不支持原生子模块，所谓“内部子模块”实为独立module：各子目录需自建go.mod，通过require引用并配合git tag发版；90%场景推荐单module+internal目录分层。
Go 用 模块（module） 管理依赖，子模块不是 Go 原生概念，但可通过多 module 目录结构实现“内部子模块”协作——本质是多个独立 module 之间的版本化引用，而非嵌套 submodule。
子模块其实是独立 module
所谓“内部子模块”，比如项目下有 cmd/、pkg/、internal/ 或
api/ 等目录，若每个目录都运行过 go mod init example.com/myproject/pkg，它就成为一个可被其他 module 引用的独立 module。Go 不强制它们共用一个 go.mod，也不支持 Git-style 的 submodule 嵌套管理。
- 每个子目录要成为 module，必须包含自己的
go.mod文件 - 主 module 通过
require example.com/myproject/pkg v0.1.0引用它，就像引用第三方库一样 - 本地开发时可用
replace指向本地路径，避免频繁发布版本：replace example.com/myproject/pkg => ../pkg
推荐：单 module 主干结构（多数场景更简单）
90% 的内部项目不需要拆 module。把所有包放在同一个 module 下（根目录一个 go.mod），用 internal/ 控制可见性，用目录逻辑分层即可。
-
internal/service/、internal/repo/：仅本 module 可导入 -
pkg/或api/：导出给外部使用的稳定接口 - 依赖统一由根
go.mod管理，无需 replace、无需版本号、无发布负担
需要拆 module 的典型场景
只有当子目录满足以下至少一条时，才值得独立成 module：
- 需被多个不同项目复用（如通用 SDK、中间件 client）
- 有独立发版节奏（如 API schema 每月一版，核心 service 每周一版）
- 团队或仓库隔离要求严格（如 frontend/backend 分属不同组维护）
- 需精确控制依赖传递（例如子 module 锁定特定版本的 grpc，不被主 module 升级影响）
协作要点：版本与发布不能少
一旦拆 module，就必须走语义化版本 + git tag 流程，否则其他模块无法可靠引用。
- 每次变更后，在子 module 目录执行：
git tag v0.2.1 && git push origin v0.2.1 - 主 module 中运行
go get example.com/myproject/pkg@v0.2.1更新 - 慎用
replace上线前务必删掉，否则构建环境会失败
基本上就这些。Go 的模块模型不鼓励“内部子模块”的复杂嵌套，优先用单 module + 目录规范 + internal 约束，真有多版本/多团队/多仓库需求，再按标准 module 方式拆分和发布。
