Go modules是唯一官方支持的多包版本管理机制，需用replace处理本地开发、vX.Y.Z格式打tag、go get -u=minor/patch配合go mod tidy确保依赖一致性。
Go modules 是唯一可行的多包版本管理机制
Go 1.11 引入 modules 后，go mod 就是官方且唯一的多包（跨 module）版本协调方案。GOPATH 模式、vendor 目录手动同步、或用第三方工具（如 dep）管理多个本地包，现在不仅过时，还会在 go build 或 go list -m all 中触发不一致警告甚至失败。
关键判断：如果你有多个本地包（比如 github.com/yourorg/liba、github.com/yourorg/libb），又希望它们被主项目统一约束版本（例如都用 v0.3.2），就必须让它们各自是独立 module，并在主项目中通过 replace 或发布 tag 控制依赖解析路径。
本地多包开发时，用 replace 覆盖远程路径
当你同时修改 liba 和依赖它的 app，但 liba 还没发版，go.mod 默认仍会拉取远程最新 tag（比如 v0.3.1），导致本地改动不生效。
解决方式是在 app/go.mod 中显式 replace：
立即学习“go语言免费学习笔记（深入）”；
replace github.com/yourorg/liba => ../liba
注意点：
-
../liba必须包含有效的go.mod（哪怕只是module github.com/yourorg/liba） - 路径是相对于当前
go.mod文件的位置，不是执行命令的位置 - 若
liba又依赖libb，而你也正在改libb，需在liba/go.mod里也加replace，否则app的 replace 不会穿透生效 -
replace仅在当前 module 生效，不会被下游自动继承；发布前必须删掉或改用require+ tag
发布多包时，tag 名称必须匹配语义化版本格式
Go modules 严格按 vX.Y.Z 解析版本，v1.0、1.0.0、release/v1.2.3 都无效。如果你运行 go get github.com/yourorg/liba@v1.0.0 失败，大概率是 tag 写成了 1.0.0 而非 v1.0.0。
验证方式：
- 执行
git tag看输出是否含v前缀 - 在空目录下
go mod init tmp && go get github.com/yourorg/liba@v1.0.0，观察是否报unknown revision v1.0.0 - GitHub/GitLab 页面上点击 tag，URL 路径应为
/tree/v1.0.0，而非/tree/1.0.0
一旦 tag 格式错误，即使代码正确，其他项目也无法通过版本号可靠引用——这是多包协作中最常被忽略的硬性门槛。
升级多包依赖时，go get -u 默认只升一级，不是全量递归
执行 go get -u ./... 并不会把所有间接依赖（indirect）都升级到最新兼容版，它只更新直接依赖及其满足 require 约束的最小版本。例如 liba require golang.org/x/text v0.3.7，而 libb require v0.12.0，go get -u 会选择 v0.12.0（更高者胜出），但不会主动把 liba 的 require 行改成 v0.12.0。
真正要同步多个包的依赖树，得用：
-
go get -u=patch ./...：只升 patch 版本（安全） -
go get -u=minor ./...：升 minor，可能含 breaking change - 对每个包单独进目录跑
go get -u，再回到主模块go mod tidy，才能确保go.sum与各子 module 的实际需求一致
跳过 go mod tidy 直接提交 go.mod，会导致 CI 构建时因 checksum 不匹配失败——这个细节在多人协作的多 module 仓库里几乎必踩一次。
