go mod tidy 只删除 go.mod 中未被 import 引用的依赖声明，不清理磁盘上的模块缓存（$gopath/pkg/mod）、vendor 目录或旧版本残留；需手动执行 go clean -modcache 清空缓存，再配合 rm -rf vendor && go mod vendor 重生成 vendor 才能彻底释放空间并确保一致性。
不能只靠 go mod tidy 彻底卸载未使用的模块依赖——它只改 go.mod，不碰磁盘上的模块缓存、vendor 目录或旧版本残留。
为什么 go mod tidy 看似删了依赖，但磁盘空间没变
因为 go mod tidy 只修改 go.mod 和 go.sum，不会删除 $GOPATH/pkg/mod 里已下载的模块文件。那些被移出 go.mod 的模块版本，依然躺在磁盘上，占着空间，还可能干扰后续 go list -m all 输出或 CI 构建行为。
-
go mod tidy删除的是声明，不是文件 - 模块缓存（
$GOPATH/pkg/mod）默认终身留存，除非手动清理 - 如果项目用过
replace或旧版间接依赖，tidy不会自动清掉缓存中对应路径 - 执行
go clean -modcache后首次go build会慢，但这是“真正干净”的代价
如何安全清空本地模块缓存
运行 go clean -modcache 是唯一可靠方式，它会递归删除整个 $GOPATH/pkg/mod 目录。注意：这不是“选择性删除”，而是全量清空。
Golang Google Wire
下载
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
- 先确认当前
GOPATH：go env GOPATH（通常为$HOME/go） - 执行：
go clean -modcache（无需 sudo，也不建议加sudo） - 验证是否清空：
ls $(go env GOPATH)/pkg/mod应报错 “No such file or directory” - 之后再跑一次
go mod tidy，Go 会按需重新拉取当前项目真正需要的最小集合
vendor 目录里的冗余包怎么处理
go mod vendor 生成的 vendor/ 是独立副本，go mod tidy 对它完全无感。想精简 vendor，必须在 go mod tidy 清理完 go.mod 后，**重新生成 vendor**。
- 先确保
go mod tidy已完成，且go build ./通过 - 删旧 vendor：
rm -rf vendor - 重生成：
go mod vendor - 若想看哪些包被跳过（即未参与当前构建），可用：
go mod vendor -v 2>&1 | grep 'skipping' - 注意：vendor 中的包路径和
go.mod版本必须严格一致，否则go build -mod=vendor会失败
哪些依赖 go mod tidy 明明没用却删不掉
这些不是 bug，是设计使然——go mod tidy 依赖静态 import 分析，对运行时行为无感知。以下情况它必然保留模块：
- 空白导入：
import _ "github.com/lib/pq"→ 被视为显式依赖 - 仅用于
//go:embed或//go:generate的包 → 没 import 就不算引用 - 测试文件（
*_test.go）里的 import → 默认扫描，但若用了//go:build !test则可能漏掉 - 通过反射加载的包（如
plugin.Open、reflect.ImportPath）→ 静态分析无法捕获 - 被其他已保留模块间接依赖的
// indirect条目 → 即使你代码没直接 import，只要链路存在就不会删
真正难处理的是 init() 注册型依赖（比如数据库驱动），它们不暴露函数，只靠 import 触发注册——删了就 panic，但 go mod tidy 无法判断这种副作用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
