go不会自动更新依赖，所谓“自动破坏”实为命令或配置不当导致版本漂移：如go.mod未锁死语义化版本、间接依赖拉高版本、ci中误用go mod tidy或go get -u等。
Go 本身不会自动更新依赖，所谓“自动破坏”其实是操作或配置触发了非预期的版本漂移。 核心问题不在 Go 工具链，而在你执行的命令、go.mod 的写法、CI 流程是否放任 go mod tidy 或 go get -u 自由运行。
为什么 go.mod 里写了 v1.9.3，build 时却用了 v1.10.0
这是最典型的“看似自动升级”现象。根本原因不是 Go 主动换版本，而是：go.mod 中的版本声明没锁死语义化范围，或者有其他依赖间接拉高了版本。
- 如果你只写
require github.com/gin-gonic/gin v1.9.3，它仍是合法的^1.9.3范围 —— 当 v1.10.0 发布后，go get -u或go mod tidy（在某些上下文里）会按 MVS 算法选 v1.10.0，只要没 break import 兼容性 - 另一个常见原因是：某个你没直接 require 的模块（比如
github.com/xxx/yyy）依赖了gin v1.10.0，而你又没在go.mod中显式约束gin版本，MVS 就会提升整个图里的gin到 v1.10.0 来满足它 -
go.sum不参与版本选择，只做校验；它存在与否、内容新旧，都不影响go mod tidy选哪个版本
用 replace 和 // indirect 显式压制浮动
当某依赖反复被间接拉高，又不能立刻升级主项目代码适配，replace 是最直接的刹车方式。
- 在
go.mod末尾加一行：replace github.com/gin-gonic/gin => github.com/gin-gonic/gin v1.9.3 - 这行优先级高于
require，所有 import 都会强制走这个版本，无论其他模块怎么声明 - 如果只是想让某个间接依赖“不升级”，但又不想全局 replace，可先用
go mod graph | grep gin找出谁在拉高它，再在go.mod里对那个模块加require并锁死其版本，把它从// indirect变成 direct，从而接管其版本控制权
CI 和本地开发必须禁用隐式升级行为
很多构建失败发生在 CI，因为流水线每次 clean + go mod tidy，而此时上游刚好发布了新 patch 版本 —— 构建结果就不可重现。
- CI 中应避免无条件运行
go mod tidy；改为go mod download+go build，跳过解析和修改go.mod - 禁止在 CI 脚本里出现
go get -u、go get -u ./或go get -u all；如需更新，必须带明确版本号，例如go get github.com/sirupsen/logrus@v1.9.3 - 本地开发时，把
GOFLAGS="-mod=readonly"加进 shell profile；这样任何会修改go.mod的命令（如go get）都会直接报错，逼你意识到“我在改契约”
go.sum 不是摆设，它是最后一道防线
go.sum 文件记录每个模块版本对应的校验和，Go 工具链会在下载时严格比对。但它只有在被提交、且未被忽略时才起作用。
- 必须把
go.sum提交到 Git —— 它不是生成文件，是依赖内容的指纹契约 - 如果某次
go mod tidy后go.sum改变了，说明依赖内容实际变了，这不是“自动更新”的锅，是你允许了变更发生 - CI 中加一句
git status --porcelain go.sum | grep -q '.' && (echo "go.sum changed unexpectedly"; exit 1)，能快速捕获静默污染
真正容易被忽略的点是：你以为锁死了版本，其实只是锁死了 direct 依赖；而间接依赖的版本是由整个模块图共同决定的。不看 go list -m all 输出，不查 go mod graph，光靠眼瞅 go.mod 里的几行 require，根本没法判断实际加载的是哪个 commit。
