应禁用 go get -u，因其会升级 minor 版本破坏 API 兼容性；生产环境须显式指定版本如 go get github.com/gin-gonic/gin@v1.9.1，并在 CI/CD 中校验版本范围。
别用 @latest 自动更新，它不是“省事”，是埋雷。
go get -u 会悄悄升级次版本，破坏 API 兼容性
执行 go get -u github.com/gin-gonic/gin 不只是升 patch 版本（如 v1.9.1 → v1.9.2），而是可能跳到下一个 minor 版本（v1.9.x → v1.10.0）。而 Go 的语义化版本约定中，minor 升级允许新增导出函数、修改行为，但不保证向后兼容——gin.Engine.Use() 在 v1.10 中参数签名变更就是典型例子。
- 生产环境应禁用
go get -u，改用显式版本指定：go get github.com/gin-gonic/gin@v1.9.1 - CI/CD 流程里可加检查：运行
go list -m -f '{{.Version}}' github.com/gin-gonic/gin，比对是否超出预设范围（如>=v1.9.0,<v1.10.0>）</v1.10.0> - 若必须批量更新，用
go get -u=patch限定只升补丁版，避免意外 break
go mod tidy 不等于安全，它会保留间接依赖的旧版本
go mod tidy 只清理未被 import 的直接依赖，但不会主动降级或剔除已存在的间接依赖。比如你删掉了某处 import "github.com/sirupsen/logrus"，go mod tidy 会移除 logrus；但若 logrus 是通过 github.com/urfave/cli 间接引入的，且 cli 仍引用 v1.8.0，那 logrus v1.8.0 就会留在 go.mod 里，哪怕你项目里早已不用它。
- 定期运行
go list -m all | grep logrus查看实际加载的版本，确认是否来自预期路径 - 发现冗余间接依赖时，用
go get github.com/urfave/cli@v2.3.0（假设新版已升级其自身依赖）来触发 MVS 重算 - 不要手动删
go.mod里的 require 行——Go 工具链不认这种“人工 tidy”
私有模块 + GOPRIVATE 导致版本漂移更隐蔽
当模块路径匹配 GOPRIVATE（如 GOPRIVATE=git.internal.company.com/*），Go 会跳过代理校验，直接从 Git 服务器拉取。问题在于：如果团队没强制打 tag，go get git.internal.company.com/utils@main 实际拉的是 latest commit hash，每次构建都可能不同。
立即学习“go语言免费学习笔记（深入）”；
- 私有模块也必须打语义化 tag（
v1.2.0），禁止用@main或@master引入 - 在 CI 中加一步：
git ls-remote origin refs/tags/v*检查 tag 是否存在，再执行go get -
go.sum对私有模块只记录 commit hash，不校验 tag 名——这意味着你看到v1.2.0在go.mod里，但go.sum里可能是abcdef12345，而这个 hash 可能对应任意一个未打 tag 的提交
真正麻烦的不是版本怎么升，而是“谁在什么时候、以什么方式、把哪个依赖的哪个版本悄悄塞进了构建”。go list -m all 和 go mod graph 要养成每周扫一眼的习惯，尤其在合并 PR 前——很多 breakage 都藏在别人加的一行 import 里。
