go mod tidy仅补全未声明的直接依赖并删除完全未使用的模块，不清理间接依赖或vendor；其采用最小版本选择机制导致间接依赖升级，需手动固定版本。
go mod tidy 不是“一键清理垃圾”的魔法命令，它只做两件事：补全你代码里 import 了但没声明的依赖，删掉你代码里完全没 import 的模块。其他一概不管。
为什么 go mod tidy 后依赖版本变了？
它默认采用最小版本选择（MVS）机制，会把间接依赖升到满足所有直接依赖的最新兼容版。比如 golang.org/x/net 可能从 v0.7.0 跳到 v0.25.0，而这个升级不会报错，但可能引入行为变更。
- 想锁死某个间接依赖？不能靠
go mod tidy，得先go get golang.org/x/net@v0.7.0，再跑 tidy - 检查谁拉进了这个包：
go mod graph | grep "golang.org/x/net" - 确认是否真被间接引用：
go list -m all | grep "golang.org/x/net"，如果带// indirect就是传递依赖 - CI 中频繁因版本漂移失败？固定
GOPROXY和GOVERSION，别让 tidy 在不同环境选不同版本
go mod tidy 删不掉某些模块？
它只删「既没被你的代码 import、也没被任何保留下来的依赖所依赖」的模块。只要某模块出现在依赖链里（哪怕只是 A → B → C，而你只 import A），它就会留下。
- 常见误判场景：
import _ "github.com/gorilla/mux"被注释或删除后，go mod tidy才会删它；但若logrus内部用了golang.org/x/sys，即使你没 import，它也不会删 - 想确认某模块是否真冗余：先临时删掉疑似相关的
import行，再跑go mod tidy—— 如果它从go.mod消失了，说明就是被那行引来的 - 注意 IDE 或
go工具链自身调用的模块（如golang.org/x/tools），这类即使代码没 import，也不建议手动强删
运行前必须检查的三件事
盲目执行 go mod tidy 容易污染 go.mod，尤其在团队协作中引发 diff 冲突。
立即学习“go语言免费学习笔记（深入）”；
- 确保当前工作区干净：
git status无未提交变更，或至少go build ./和go test ./全部通过 - 确认
GO111MODULE=on（Go 1.16+ 默认开启，但老项目或 CI 环境可能关闭） - 检查
go.mod第一行的 Go 版本声明是否与本地go version匹配；不一致时，先手动改go 1.21这类行，再 tidy - 多 module 项目（如含
./cmd/子目录）？别在根目录一股脑 tidy —— 进入./cmd/app后go mod init example.com/cmd/app+go mod tidy独立管理
vendor 目录和 go.sum 的坑
go mod tidy 完全不碰 vendor/ 目录。它只更新 go.mod 和 go.sum，且对 go.sum 的处理有隐藏逻辑：
-
go.sum缺失或损坏时，tidy 会重生成，但不会校验已有 checksum 是否匹配远程包——这意味着可能静默替换成不同内容的同名版本 - 要同步 vendor：
go mod vendor；想强制刷新（包括删掉已不存在的模块），加-v -o ./vendor - 手动改过
vendor/modules.txt或删过子目录？go mod vendor默认不会恢复，它只按当前go.mod+go.sum忠实复制 -
replace指向本地路径时，若该路径下没有go.mod，tidy 会直接报错退出，不是警告
真正容易被忽略的是：tidy 的结果高度依赖环境一致性。同一份代码，在你本地、同事机器、CI 流水线里跑出不同的 go.mod，往往不是命令问题，而是 GOPROXY、GOVERSION、甚至 Go 工具链小版本差异导致的解析路径不同。
