go.mod 的 exclude 是什么，它真能“排除依赖”吗？
不能。它只在 go build、go test 等命令的模块加载阶段跳过指定版本的模块，不影响 go list -m all 或 go mod graph 的结果，也不阻止该版本被间接引入——只要某个未被 exclude 的依赖还引用它，它就仍会出现在最终构建中。
典型误用场景：看到 github.com/some/pkg v1.2.3 有 panic，就加 exclude github.com/some/pkg v1.2.3，以为万事大吉。结果发现 go run main.go 还是崩了——因为另一个依赖 github.com/other/lib 显式要求了 v1.2.3，而 exclude 不会重写其 go.mod 中的 require。
-
exclude不修改依赖图，只影响主模块的版本选择逻辑 - 它不解决根本问题（比如 API 不兼容），只是临时绕过某个版本参与最小版本选择（MVS）
- 如果被 exclude 的版本是唯一满足某依赖约束的版本，
go build会报错：invalid version: excluded version github.com/some/pkg v1.2.3 is required
什么时候该用 exclude，而不是 replace 或升级依赖？
仅当你要临时屏蔽一个已知有问题、但又无法立刻从整个依赖链中清除的版本，且你确认其他路径不会强制拉入它。常见于：上游模块发布了破坏性 patch（如 v2.1.5 引入 panic），但你暂时没法等它发 v2.1.6 修复，也不能改自己所有直接/间接依赖的 go.mod。
- 优先考虑
replace：如果你有本地修复或 fork 分支，用replace github.com/some/pkg => ./fix-pkg更可控 - 优先升级依赖：如果
github.com/other/lib已发布新版并弃用了问题版本，改它的require比全局exclude更安全 -
exclude是最后手段，且必须配合go mod tidy验证是否生效——它不会自动删掉go.sum中的记录，也不会清理缓存
exclude 后为什么 go list -m all 还显示被排除的版本？
因为 go list -m all 展示的是模块图的静态快照，包含所有显式 require 和传递依赖，而 exclude 是运行时过滤策略，只在构建、测试、vendor 等阶段起作用。这容易让人误判“排除失败”。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
验证是否真正生效，得看构建行为：
- 执行
go build -x，搜日志里有没有github.com/some/pkg@v1.2.3的unzip或compile行 - 运行
go mod graph | grep 'some/pkg'，确认输出中不含v1.2.3（注意：如果其他模块 require 它，仍可能出现在图中；exclude只影响主模块选版，不删边） - 检查
go.mod中对应模块是否被降级到更早的兼容版本（如v1.2.2），这才是exclude起效的标志
多个 exclude 条目和版本范围陷阱
go.mod 不支持通配符或版本范围语法，每个 exclude 必须写死完整模块路径 + 版本号。想排除 v1.2.0 到 v1.2.9？得手写 10 行。
- 别写
exclude github.com/some/pkg v1.2.*—— 会报错：syntax error in go.mod - 别指望
exclude github.com/some/pkg v1.2.3能顺带挡住v1.2.4，哪怕它更糟 - 如果多个
exclude冲突（比如同时 excludev1.2.3和v1.2.4），Go 工具链会全部应用，但最终选哪个替代版本，取决于 MVS 规则和剩余可用版本 - CI 环境下务必确保
go mod download之前已写入exclude并git add go.mod，否则本地有效、CI 失效
真正麻烦的从来不是怎么写 exclude，而是搞清它到底拦住了谁、又放过了谁——尤其当依赖树深、多模块共存时，一个 exclude 可能只在部分子命令中起效，换条命令就失效。
