是，go mod tidy 会自动删除未使用的依赖，但仅当模块为主模块且无其他模块显式 require 时，它基于构建图做可达性分析而非简单扫描 import。
go mod tidy 会自动删掉未使用的依赖吗
会，但只在模块处于“主模块”（即当前目录有 go.mod 且 GO111MODULE=on）且没有其他模块显式 require 它时才删除。它不是简单地扫描 import 语句，而是基于整个构建图做可达性分析：
go mod tidy
会重新计算所有 import 路径的传递闭包，移除不在该闭包中的 require 条目。
常见误判场景：
- 代码里用
_ "some/module"方式导入但没实际调用 ——go mod tidy仍会保留，因为下划线导入本身就算使用 - 测试文件（
*_test.go）里用了某模块，但主代码没用 —— 默认会保留，除非加-compat=1.16或更高版本且测试未被go test实际触发 - 使用了
//go:embed或//go:generate引用某包，但没 import —— 不会被识别为依赖，go mod tidy会误删
更新某个特定模块到最新版的正确命令
别直接改 go.mod 文件手动编辑版本号，容易出错。推荐用 go get 显式升级：
- 升级到最新 tagged 版本：
go get example.com/some/module@latest
- 升级到指定 tag：
go get example.com/some/module@v1.2.3
- 升级到某次 commit：
go get example.com/some/module@abcd123
- 如果只想升级间接依赖（transitive），先确认它是否被直接 require；否则需先
go get直接依赖，再go mod tidy推导
注意：go get 默认会写入 go.mod 并自动运行 go mod tidy（Go 1.16+），但不会自动 go mod vendor。
立即学习“go语言免费学习笔记（深入）”；
为什么 go mod tidy 后 vendor 目录没更新
go mod tidy 只管 go.mod 和 go.sum，和 vendor/ 无关。要同步 vendor，必须额外执行：
go mod vendor
常见疏漏点：
- 没加
-v参数时，go mod vendor默认只 vendoring 构建所需模块，不包含测试依赖 —— 如需完整复制，用go mod vendor -v - 执行前未确保
go.mod已是最新的（比如刚go get但忘了go mod tidy），会导致 vendor 内容陈旧 - CI 环境中若设了
GOPROXY=off，go mod vendor会失败，因无法拉取 module zip 包
go.sum 文件冲突时该怎么处理
go.sum 不是“可合并”的文本文件，它是每个 module 的校验和快照。多人协作时出现冲突，**不要手动编辑或删行**。正确做法是：
- 先
git checkout拿到双方的go.mod（可能已合并好） - 运行
go mod tidy
—— 它会重生成
go.sum，覆盖所有冲突内容 - 检查输出是否有
verify failed错误；若有，说明某 module 的哈希不匹配，可能是中间人篡改或缓存污染，需清空$GOPATH/pkg/mod/cache后重试
关键点：只要 go.mod 正确，go.sum 就可完全重建；它的作用只是校验，不是状态记录。