应先用go list -u -m all扫描可安全升级的包，重点关注标有[newest]的候选版本，避免盲目go get -u；v0.x包无兼容承诺，升级风险极高；私有模块须打tag后显式拉取，replace仅限临时调试。
升级前先看哪些包能升，别盲目 go get -u
直接跑 go get -u ./ 是最常见也最容易翻车的操作。它会递归升级所有间接依赖到最新 minor/patch 版本，而很多 v0.x 或未严格遵循 SemVer 的包，一次补丁更新就可能改掉函数签名或返回类型。
正确做法是先用 go list -u -m all 扫一遍，只列出当前 go.mod 中有明确 require 且存在新兼容版本的包。输出里带 [newest] 的才是安全可升的候选。
- 重点关注
v0.x版本包——它们没有兼容性承诺，-u升级风险极高 - 忽略那些显示
(latest)但没标[newest]的包，说明当前约束已满足最新版 - 如果某包显示多个可用版本（如
v1.2.3和v1.3.0），优先选小版本号更保守的
升级单个包时，@latest 和 -u 行为完全不同
go get github.com/sirupsen/logrus@latest 会尝试拉取该模块所有 tag 中语义版本最高的那个（比如 v2.4.0），哪怕你原来依赖的是 v1.8.1 ——这本质是跨主版本升级，很可能 break 编译。
而 go get -u github.com/sirupsen/logrus 只会在满足当前 go.mod 中已有约束的前提下（例如 require github.com/sirupsen/logrus v1.8.1），升级到 v1.x 系列里最新的 patch/minor 版本（如 v1.9.3）。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 日常维护建议用
go get -u <pkg>，不是@latest - 真要上
v2，必须手动改import路径（如从"github.com/sirupsen/logrus"改成"github.com/sirupsen/logrus/v2"），再go get github.com/sirupsen/logrus/v2@v2.0.0 - 升级后立刻运行
go mod tidy，否则go.sum缺失校验项，CI 构建会失败
私有模块升级必须打 tag，replace 只能用于开发
内网 GitLab 或 Gitea 上的私有模块，升级不是改本地代码再 go mod tidy 就完事。Go 工具链只认 go.mod 里 require 声明的版本，不感知你本地文件是否改动过。
标准流程是：在私有仓库打 tag（如 v0.3.1）→ 推送到远端 → 主项目执行 go get git.example.com/team/utils@v0.3.1。
-
replace是临时调试手段，例如replace git.example.com/team/utils => ./local-utils，上线前必须删掉 - CI/CD 流水线里若残留
replace，构建会因路径不存在直接失败 - 私有域名无法解析时，需配
GOPRIVATE=git.example.com，否则 Go 默认跳过 TLS 校验
go mod tidy 不是万能清洁工，它不会解决版本冲突
go mod tidy 只负责补全缺失依赖、删掉未引用的 require，但它不判断版本是否合理。当两个不同依赖都要求同一个包的互斥版本（比如 A 要 v1.5.0，B 要 v1.7.2），tidy 会按 MVS 算法选一个“最小可行版本”，但这个版本未必能让所有代码跑通。
- 遇到编译失败或运行时 panic，先用
go mod graph | grep pkgname查谁在拉这个包 - 再用
go mod why pkgname看为什么需要它，定位冲突源头 - 必要时在
go.mod里显式require一个中间版本（如github.com/pkg/errors v0.9.1），强制统一 - 缓存异常导致版本拉错？
go clean -modcache清掉重来
go.sum 是否被意外修改。每次升级，go test ./... 和 go mod verify 这两步不能跳。 
