go mod tidy仅删除未被import语句引用且无间接依赖的模块，无法识别反射调用、配置驱动、构建标签启用或测试专用模块，需人工交叉验证并配合go mod why、-v日志及go list等命令综合判断。
高频运行时累积的“冗余配置”不是 Go 模块系统原生概念——你真正要处理的是三类东西：缓存污染、构建状态残留、以及被误判为“活跃”的间接依赖。
go mod tidy 为什么对高频运行无效
它只看 import 语句的静态结构，不感知运行时行为。你在循环里用 reflect.Value.Call 加载插件、通过 JSON 配置动态 import 包名、或在 //go:build integration 下才启用的模块，go mod tidy 全部看不见。高频运行不会让这些模块“变冗余”，但会让它们的缓存和构建产物堆积更快。
- 高频执行
go test -tags=integration会反复下载/解压对应模块，但go mod tidy默认不启用该 tag，所以它认为那些模块“未引用”，可能误删 -
go mod tidy -v输出里出现反复adding ... // indirect→removing ...，说明构建标签不一致或replace冲突，不是 tidy 能解决的 - 空白导入如
import _ "github.com/lib/pq"若仅靠 init 注册驱动，go mod why -m github.com/lib/pq可能返回(main module does not need module)，但删了就 panic
清理 $GOMODCACHE 时必须绕开 vendor 和私有代理陷阱
go clean -modcache 会清掉所有模块源码和 zip 包，但它不区分来源。如果你用了私有代理（比如 Nexus），而 go env GOPRIVATE 没设全，清理后 go build 可能拉错版本，甚至跳过校验。
Golang Google Wire
下载
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
- 先确认
go env GOPRIVATE是否包含所有内部域名，例如git.internal.company.com,*.corp.example.org - 不要直接
rm -rf $GOPATH/pkg/mod—— 它会删掉cache/download里的校验文件（.info），导致后续go get无法验证 checksum - 更稳妥的做法是：保留
go.sum，执行go clean -modcache，再立刻跑go mod verify；失败则说明私有模块签名不匹配，得检查代理配置
高频构建下真正该清的是 $GOCACHE，不是模块本身
你观察到的“冗余配置感”，大概率来自 $GOCACHE 里堆积的跨平台/CGO 构建产物。每个 GOOS/GOARCH 组合、每个 CGO_ENABLED 状态都会生成独立的 .a 文件，它们不会自动过期。
立即学习“go语言免费学习笔记（深入）”；
- 执行
go clean -cache后构建变慢是正常现象——它删的是编译中间产物，不是源码 - 若你频繁切换
CGO_ENABLED=0和1，必须清 cache，否则链接时静默失败（错误不报在 build 阶段，而是在 runtime） - CI 环境建议直接设
GOCACHE=$(mktemp -d)，构建完自动销毁，比清理更可靠
验证是否真清干净，别信输出日志
go clean -modcache 成功后控制台不报错，不代表模块没残留；go mod tidy 结束也没提示，不代表依赖图已收敛。高频场景下，最易被忽略的是：
-
go list -m all | wc -l对比前后数字——下降才说明删了东西，否则只是缓存重建 -
go mod graph | grep "your-module-name"查有没有孤立节点（即没被任何路径引用却仍留在图里） - 运行
go build -a ./（强制重编译所有包），再看lsof +D $(go env GOCACHE)是否还有进程持旧句柄——IDE 或后台分析工具常锁住缓存文件，空间不会立刻释放
