go mod tidy会补全缺失依赖并删除未引用的模块，但不会自动升级或解决版本冲突。需先确保代码可构建、go.mod存在且GO111MODULE开启；常用操作包括配合go get升级、手动修改版本后tidy验证，注意SemVer规则、replace/exclude陷阱及GOPRIVATE配置，依赖管理最终仍需人工决策。
使用 go mod tidy 并不是简单运行一条命令就完事，它背后涉及模块初始化、依赖拉取、版本解析和最小版本选择（MVS）机制。关键在于理解它“做什么”和“不做什么”，才能避免误删、错升或版本不一致问题。
go mod tidy 的核心作用
它会做两件事：
– 自动补全 go.mod 中缺失的 require 条目（比如你代码里 import 了但没声明）
– 自动删除未被直接 import 的模块依赖（即没有被当前 module 显式引用的间接依赖）
但它不会自动升级已有依赖的版本，也不会强制统一子依赖的版本冲突——这些需要手动干预或配合其他命令。
清理依赖前的必要准备
确保项目处于干净状态再执行 tidy，否则容易引入意外变更：
– 运行 go build ./... 或 go test ./... 确认代码可正常编译和测试
– 检查 go.mod 文件是否已存在；若无，先执行 go mod init your-module-name
– 确认 GO111MODULE=on（Go 1.16+ 默认开启，但老项目或环境变量可能关闭）
常用组合操作与典型场景
只清理，不升级：直接运行 go mod tidy —— 它只会增删 require 行，保持现有版本不变。
升级单个依赖到最新版：先 go get example.com/some/pkg@latest，再 go mod tidy
降级或锁定特定版本：编辑 go.mod 手动改写对应 require 行（如 example.com/some/pkg v1.2.0），然后运行 go mod tidy 验证一致性
查看为什么某个模块被保留：用 go mod graph | grep "module-name" 查依赖链，或 go list -m all | grep "module-name"
版本规范与常见陷阱
Go 默认采用语义化版本（SemVer），但实际行为受以下影响：
– 若依赖未打 tag，go 会使用 commit hash（如 v0.0.0-20230101000000-abcdef123456）
– 同一模块不同子路径（如 a/b 和 a/c）可能被解析为不同版本，导致重复引入
– replace 和 exclude 指令需谨慎使用：前者绕过代理/校验，后者仅在构建时忽略，tidy 仍会保留 require 行
– 私有模块需配置 GOPRIVATE 环境变量，否则 tidy 可能因无法访问而失败
基本上就这些。go mod tidy 是个“守门员”，不是“决策者”。依赖怎么选、版本怎么定，得靠人来判断；它只是帮你把结果整理干净、保持一致。