go mod tidy 是唯一能安全删除无用模块的官方手段，它只删除既未被任何.go文件import、也未被其他保留模块间接引用的模块；注释导入、条件编译、空白导入、测试专用及运行时反射加载的依赖均无法被自动识别，需人工验证。
go mod tidy 是唯一能安全删除无用模块的官方手段，但它不会自动删掉所有“看起来没用”的模块——它只删那些既没被任何 .go 文件 import，也没被其他保留模块间接引用的模块。盲目手动删 go.mod 里的 require 行，大概率导致构建失败或运行时 panic。
哪些模块会被 go mod tidy 真正删掉
它不是按“有没有调用函数”判断，而是严格按 import 语句存在性 + 传递依赖链是否断裂来决定：
- 注释掉的
import "net/http"→ 不算，对应模块可能被删 - 仅在
//go:embed或//go:generate中出现的模块（如//go:generate go run github.com/xxx/cmd）→ 不算 import，会被删 - 只用于测试文件（
*_test.go）且运行go mod tidy时未启用测试模式 → 默认不扫描，可能误删 -
import _ "github.com/lib/pq"（空白导入）→ 算显式依赖，会被保留 - 模块被
replace指向本地路径，但该路径下实际没被 import → 仍可能被删（tidy只看 import，不验证replace目标是否有效）
为什么 go mod tidy 没删掉你认为“无用”的模块
常见错觉是“我没调用这个包，它就该删”，但 Go 的依赖判定只看 import 是否存在，不管是否执行：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 模块被某个已保留依赖的
go.mod显式require→ 它会作为间接依赖保留在你的go.mod中，带// indirect标记 - 代码里有
import "github.com/sirupsen/logrus"，哪怕一行 log 都没打 → 它就会被保留 - 用了
//go:build linux的文件，但当前环境是GOOS=windows→ 里面 import 的模块不会被识别，可能误删 - 依赖通过
plugin.Open()或reflect.ImportPath()动态加载 →tidy完全看不见，绝不会删
安全清理前必须验证的三件事
跳过这步直接 go mod tidy，容易在 CI 或生产环境出问题：
- 先确保所有生成代码已更新：跑一遍
go generate ./，否则gen.go里 import 的包可能被漏掉 - 确认测试能过：
go test ./成功，因为_test.go里的 import 只有在测试上下文中才被tidy认可 - 检查多平台构建需求：如果项目要支持
js或wasm，得分别用GOOS=js go list -deps ./看是否引入额外依赖，再决定是否保留
go mod tidy 后 vendor 目录没变？这是正常现象
go mod tidy 默认只改 go.mod 和 go.sum，完全不碰 vendor/ 目录：
- 想同步
vendor/，必须加-v参数：go mod tidy -v - 如果之前已有
vendor/，它不会自动删掉已删除模块的旧文件 —— 得先rm -rf vendor/，再go mod tidy -v - CI 环境慎用
go mod vendor：它会把 test-only 依赖也拉进去，增大镜像体积；更推荐go build -mod=readonly+ 干净缓存
真正难处理的是那些靠 init() 注册、靠字符串反射加载、或只在特定构建标签下才激活的依赖——它们永远逃得过 go mod tidy 的静态分析，只能靠人工核对和运行时验证。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
