Go Modules 不支持 monorepo 统一管理共享依赖版本，因其设计哲学是各模块独立解析与锁定；不存在 workspace 机制，无跨模块依赖池或版本继承语法，强行同步会破坏 go.sum 校验且无法保障编译通过。
Go 的 monorepo 多包项目里，**不存在“统一管理共享依赖版本”这个需求本身**——Go Modules 的设计哲学是每个 go.mod 独立解析、各自锁定，强行“统一”不仅不可行，还会掩盖真实依赖冲突。
为什么不能像 pnpm workspace 那样统一声明依赖？
Go 没有 workspace-level 的依赖池机制。每个子模块（如 /pkg/core、/cmd/api）只要带自己的 go.mod，就构成一个独立的 module，其 require 条目由自身构建上下文决定。即使它们在同一个 Git 仓库里，go build ./... 也不会跨目录合并或对齐版本。
-
go list -m all在根目录执行，只反映当前目录（或指定模块）的解析结果，不是“全仓视图” - 没有类似
{ workspace = true }的继承语法，也没有replace跨模块自动传播机制 - 试图用脚本批量改所有
go.mod中的同一行版本号，会破坏go.sum校验，且无法保证各模块实际能编译通过
真正该关注的是：谁在用哪个版本？怎么让它可追溯？
关键不是“让所有包用 v1.5.0”，而是快速定位某依赖在哪些模块中被拉入、为什么是那个版本。这靠的是 Go 原生工具链，不是人工同步：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
go mod graph | grep github.com/some/lib查看所有引入路径和对应版本 - 用
go list -m -u all找出可升级但尚未升级的模块（注意：它只报“有新版本”，不判断是否兼容） - 对核心共享库（如
/internal/shared），应在它的go.mod中显式require所有它导出类型所依赖的外部模块，并加注释说明用途 - CI 中跑
go list -m all | sort并存档，比人工维护“统一版本表”更可靠
当多个包确实需要共用同一份底层逻辑时，怎么做？
不是锁版本，而是**收口模块路径 + 强制导入约束**：
- 把共享逻辑抽成一个独立 module（如
github.com/your-org/shared/v2），发布时严格遵循/v2路径规则 - 所有业务包都直接
import "github.com/your-org/shared/v2"，而不是各自 require 不同的间接依赖 - 在
shared/v2/go.mod里用replace临时指向本地开发路径（仅限本地），CI 构建前必须删掉并运行go mod tidy - 避免在
/cmd或/internal下放多个go.mod—— 如果只是代码组织分层，不需要每个目录都是 module；只有真正需要独立发布、独立版本语义的才设go.mod
最常被忽略的一点：Go monorepo 的“一致性”不来自版本数字对齐，而来自 go.sum 文件是否被提交、CI 是否用相同 Go 版本执行 go mod tidy 和 go build。版本号只是人类可读标签，哈希才是 Go 认证的唯一依据。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
