只改了两行业务代码，跑完 `go mod tidy` 提交，CI 编译直接失败，go.mod 里多出十几个 indirect 依赖，好几个原本固定的版本号也跟着变了，本地缓存里却还是旧的。乍看像缓存或者权限的锅，追下去往往不是。
cp go.mod go.mod.bak go mod tidy -v git diff go.mod go.sum go mod graph | grep 目标模块
追下去是这么回事：tidy 会按当前主模块的导入重新计算最小版本选择，删掉不用的同时把缺失的间接依赖补到刚好满足约束的版本，主版本约束一松，整棵依赖树就跟着动，测试覆盖不到的地方先崩。
「go mod tidy 副作用」相关的验证我通常做两遍，改完一次、隔天再看一次，确认不是临时生效。接口问题先分清是没发出去、发出去了没收到，还是收到了处理失败。
偶发问题先统计频率，一小时几次和一天一次，查法完全不同。
具体做法是，运行整理命令之前先备份模块文件和校验文件；对比差异只保留这次真正需要的那部分变更；用依赖图确认这几个新版本到底是谁带进来的。
验收就看一点，模块文件的差异只剩本次真正引入的依赖，持续集成编译恢复。