Go modules是唯一官方支持的多包版本管理机制，需用replace处理本地开发、vX.Y.Z格式打tag、go get -u=minor/patch配合go mod tidy确保依赖一致性。
Go modules 是唯一能可靠协调多个本地包版本的机制，其他方式（如 GOPATH、vendor、dep）在 2026 年已全面失效，且会在 go build 或 go list -m all 中触发不一致错误。
本地多包开发必须用 replace，但路径和模块定义不能出错
当你同时改 liba 和依赖它的 app，而 liba 尚未打 tag，go.mod 默认仍会拉远程 v0.3.1，导致本地修改不生效。必须在 app/go.mod 中写：
replace github.com/yourorg/liba => ../liba
但这个 replace 能生效的前提是：
-
../liba目录下存在有效的go.mod（哪怕只有module github.com/yourorg/liba一行） - 路径是相对于
app/go.mod的位置，不是你当前 shell 所在目录 - 如果
liba又依赖libb，且你也正在改libb，那必须在liba/go.mod里也加replace——app的replace不会穿透到liba的依赖解析中
tag 必须严格为 vX.Y.Z 格式，否则其他项目根本拉不到
Go modules 只认 v1.0.0 这种带 v 前缀的语义化版本。写成 1.0.0、v1.0、release/v1.2.3 都无效。常见失败现象：
立即学习“go语言免费学习笔记（深入）”；
-
go get github.com/yourorg/liba@v1.0.0报unknown revision v1.0.0 - GitHub 页面上 tag URL 是
/tree/1.0.0而不是/tree/v1.0.0 -
git tag输出里没有v前缀
验证方法：在空目录执行 go mod init tmp && go get github.com/yourorg/liba@v1.0.0，看是否成功。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
go get -u 不会自动升级间接依赖，别指望它“全量更新”
go get -u ./ 只更新直接依赖及其满足约束的最小兼容版本，不会重写 require 行，也不会把间接依赖（indirect）升到最新。例如：
-
libarequiregolang.org/x/text v0.3.7 -
libbrequiregolang.org/x/text v0.12.0 -
go get -u会选择v0.12.0（更高者胜出），但不会把liba的require行改成v0.12.0
想让所有依赖都升到最新兼容版，得用 go get -u=patch 或 go get -u=minor，并配合 go mod tidy 清理冗余项。
replace 仅当前 module 生效，发布前必须清理或替换为 require + tag
replace 是开发期临时手段，它不会被下游项目继承。如果你发布一个 module，而它的 go.mod 里还留着 replace，下游项目 go get 时根本看不到你本地的路径映射，只会按 require 去远程拉取——结果就是版本错乱或拉不到。
发布前务必：
- 删掉所有
replace行 - 确保对应依赖已打合规 tag（
vX.Y.Z） - 用
go get your-module@vX.Y.Z在干净环境验证能否正确解析
最容易被忽略的是：replace 的路径合法性检查只在本地生效，CI 构建或他人 clone 后运行 go build 时，若路径不存在或 go.mod 缺失，会直接失败——这不是警告，是硬错误。
