go mod tidy 不能彻底清理快速迭代产生的冗余定义，必须配合人工验证和多环境 tidying 才能落地；它仅基于当前构建标签下的显式 import 分析依赖，无法识别 //go:build 条件导入、//go:embed 引用、空白导入的 init() 副作用、测试专用模块等动态或隐式依赖，易误删或漏删。
go mod tidy 不能彻底清理快速迭代产生的冗余定义，必须配合人工验证和多环境 tidying 才能落地。
go mod tidy 为什么对快速迭代项目“失灵”
它只看当前构建标签下显式 import 的路径，而快速迭代中常见这些情况：
• 模块仅在 //go:build integration 或 //go:build e2e 下被 import，但默认构建不启用 → go mod tidy 视为未引用，直接删掉
• 新增的 //go:embed 引用（如 embed config.yaml）不触发 import 分析 → 对应模块被误判为冗余
• import _ "github.com/lib/pq" 这类空白导入，若驱动注册逻辑被重构移除，tidy 不会感知 init() 是否还生效
• 测试专用模块（如 github.com/stretchr/testify）只出现在 *_test.go 中，且未加 -test 参数运行 tidy → 它们会被保留或误删，取决于当前 GOOS/GOARCH 是否匹配测试构建条件
必须在不同构建环境下分别执行 go mod tidy
快速迭代项目往往依赖多个构建变体，单一 tidy 无法覆盖全路径：
• 先清理主构建：go mod tidy -v
• 再清理集成测试路径：GOOS=linux GOARCH=amd64 go mod tidy -v -test
• 若有嵌入式目标：GOOS=js GOARCH=wasm go mod tidy -v
• 针对特定 tag：go mod tidy -v -buildmode=exe -tags integration
每次执行后，检查 go mod graph | grep your-module-name 是否仍有引用；若某模块在某个 tag 下消失，说明它只服务于该场景，需人工确认是否可删
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
间接依赖（// indirect）不能靠眼力判断
go.mod 里带 // indirect 标记的模块，不是你直接 import 的，而是传递链上某处拉进来的。快速迭代中它们最容易“滞留”：
• 运行 go list -deps -f '{{if not .Standard}}{{.ImportPath}}{{end}}' ./ | sort -u，得到实际编译时加载的所有非标准库路径
• 对比 go list -m all | grep -v 'indirect$'，找出那些没出现在 deps 列表里的 // indirect 模块
• 临时注释掉疑似冗余的 require 行，再跑 go build -a ./... 和 go test -tags=integration ./... —— 若失败，说明有隐式依赖（比如通过 reflect.Value.Call 加载插件、或 JSON unmarshal 时动态解析类型）
• 特别注意 golang.org/x/sys、golang.org/x/net 这类——即使没显式 import，也可能被 os/exec 或 http.Transport 间接拉入，删了会静默降级功能
立即学习“go语言免费学习笔记（深入）”；
清理后必须验证三类边界行为
快速迭代项目最怕“编译过、测试过，但上线就 panic”：
• go build -ldflags="-s -w" ./cmd/...：确认所有子命令二进制仍能生成，尤其注意 cmd/ 下带 build tag 的工具
• go test -race -tags=integration ./...：integration 测试常引入独立依赖，且可能跨平台，必须显式带上 tag 运行
• go run -tags=embed main.go：验证 //go:embed 路径是否仍能 resolve，因为 embed 不走 import 分析，tidy 不管，但 runtime 会报错
真正危险的不是删多，而是删掉某个 init() 注册却没被静态分析捕获的模块——比如数据库驱动、prometheus metrics collector，它们只靠空白导入生效，删了不会编译报错，但运行时连接直接失败
