go mod tidy 只删除未被当前构建环境实际 import 的依赖，包括未启用构建标签、//go:generate 未标记 +build generate 或测试文件未参与构建的包；它不清理 vendor，需手动 go mod vendor 同步。
go mod tidy 会删掉哪些依赖
go mod tidy 不是“清理无用依赖”的通用工具，它只做一件事：让 go.mod 和 go.sum 精确匹配当前模块中所有被 import 的包（直接或间接）。它不会删掉你代码里没 import、但被其他工具（如 go:generate、测试文件、未启用的构建标签）引用的依赖。
- 如果某个包只在
//go:generate注释里出现，go mod tidy会把它删掉——除非你加了+build generate标签并显式运行go generate前先go mod tidy - 测试文件（
_test.go）里的 import 会被计入，但只在go test ./...或显式包含测试时才生效；如果你用go mod tidy -v，能看到它是否“看到”了这些导入 - 带构建约束（如
// +build linux）的文件，若当前GOOS/GOARCH不匹配，里面的 import 就不会被识别，对应依赖可能被误删
为什么 go mod tidy 后 vendor 目录没更新
go mod tidy 默认不碰 vendor/。它只改 go.mod 和 go.sum。要同步 vendor，必须额外执行 go mod vendor。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
go mod vendor会按当前go.mod把所有依赖复制进vendor/，但不会自动删掉旧包——它只覆盖或新增，残留文件得手动清 - 如果想让
vendor/严格等于当前依赖图，建议先删掉整个vendor/目录，再跑go mod vendor - CI 中慎用
go mod vendor：它会下载所有依赖（包括 test-only 的），可能拖慢构建；生产构建应优先用go build -mod=readonly配合干净缓存
go mod tidy 报错 “no required module provides package” 怎么办
这个错误说明某处 import 的路径，在 go.mod 当前记录的所有模块中都找不到对应包。常见于路径拼错、模块未发布、或用了 replace 但目标不存在。
- 检查报错里的
package xxx路径，确认拼写和大小写——Go 区分大小写，github.com/user/Repo和github.com/user/repo是两个不同模块 - 运行
go list -m all | grep xxx查看该包是否在依赖树里；如果没有，说明没人真正 import 它，或是被replace指向了无效路径 - 如果用了
replace，确保replace后面的本地路径存在且含有效go.mod；临时调试可用go mod edit -replace=old=new，但别忘了提交前删掉 - 私有模块（如公司内网 Git）需配置
GOPRIVATE，否则go mod tidy会尝试走 proxy 并失败
go mod tidy 在 CI 中要不要加 -v 或 -dry-run
不要加 -dry-run（不存在这个 flag），也别依赖 -v 来判断结果是否正确。go mod tidy -v 只是输出它加载了哪些模块，不反映变更内容是否合理。
- CI 中推荐固定命令：
go mod tidy -e（-e让它在遇到错误时不中断，方便捕获输出）+ 随后检查git status -s go.mod go.sum是否为空；非空说明本地依赖状态和仓库不一致，应失败 - 避免在 CI 中自动执行
go mod tidy && git add go.mod go.sum && git commit——这会让依赖变更混在业务提交里，难以审计 - 如果项目用 vendor，CI 应校验
vendor/是否最新：跑go mod vendor后比对git status -s vendor/，有变动就报错
init() 函数悄悄拉进了一个包，而它只在特定条件下触发。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
