exclude用于排除go.mod中已知有问题的依赖版本，语法为exclude模块路径+完整语义化版本，需配合go mod tidy生效，且优先级高于replace。
go.mod 中用 exclude 排除已知问题版本
当某个依赖版本存在严重 bug、安全漏洞或 ABI 不兼容，但又无法立刻升级到修复版时，exclude 是最直接的拦截手段。它不是降级，而是告诉 Go 构建器：“这个版本绝对不能被选中”，哪怕 MVS 算法原本会选它。
常见错误现象：go build 失败并提示 undefined symbol 或 method not found，而 go list -m all 显示项目实际使用了 v1.5.2，但该版本在某次 patch 中删掉了你依赖的函数——这时查 CHANGELOG 就会发现 v1.5.0–v1.5.2 全部有问题。
-
exclude必须写在go.mod文件中，且只能作用于当前 module（不传递给下游） - 语法严格：必须写全路径 + 完整语义化版本，如
exclude github.com/sirupsen/logrus v1.5.0，不能写v1.5或~1.5.0 - 可多行
exclude，例如同时排除 v1.5.0、v1.5.1、v1.5.2 - 执行
go mod tidy后，Go 会重新运行 MVS，跳过被 exclude 的版本，尝试选下一个兼容的最高版本（如 v1.4.3 或 v1.6.0）
exclude 与 replace、require 的协作边界
exclude 单独使用常不够——它只“拉黑”，不指明“该用谁”。若排除后 MVS 找不到其他满足条件的版本，构建仍会失败。此时需配合 require 显式提升目标版本，或用 replace 指向修复分支。
使用场景：上游模块尚未发布修复版，但你已确认 v1.6.0 可用，而 v1.5.x 全系不可用。
- 先加
exclude github.com/bad/pkg v1.5.0、exclude github.com/bad/pkg v1.5.1等 - 再加
require github.com/bad/pkg v1.6.0，确保 MVS 有明确目标 - 如果 v1.6.0 还未发布，可用
replace github.com/bad/pkg => github.com/your-fork/pkg v1.6.0-rc1暂代 - 注意：若
replace指向的 commit 本身也落在被exclude的版本号范围内（如 replace 成 v1.5.2-fix），Go 会忽略该 replace —— 因为 exclude 优先级更高
exclude 不生效的典型原因
写了 exclude 却发现 go list -m all 依然显示被排除的版本，说明它没被 MVS 选中——也就谈不上“排除”。真正需要排除的是那个“被选中但不该被选中”的版本。
容易踩的坑：
- 误 exclude 了根本没出现在依赖图里的版本：先运行
go mod graph | grep pkgname，确认该版本确实被某个模块引用 - exclude 的版本号和
go.sum中记录的不一致：比如go.sum记的是v1.5.0+incompatible，但 exclude 写的是v1.5.0→ 必须写成exclude github.com/pkg v1.5.0+incompatible - GO111MODULE=off 或项目根目录无
go.mod：exclude 完全不解析，检查go env GO111MODULE是否为on - 私有模块未配
GOPRIVATE：Go 仍走 proxy.golang.org，可能绕过本地 exclude 规则
用 go mod why 验证 exclude 是否起效
排除后最怕“以为生效了，其实没动”。go mod why 能验证当前选用的版本是否还包含被 exclude 的路径。
操作步骤：
- 执行
go mod why -m github.com/bad/pkg，看输出的调用链里是否还出现 v1.5.x - 若链中仍有 v1.5.x，说明某个依赖仍在硬编码要求它，且没有其他更高版本可替代 → 此时仅 exclude 不够，得升级那个上游依赖，或用 replace 强制接管
- 若输出显示 “main module does not need github.com/bad/pkg” 或指向 v1.6.0，则 exclude 已成功阻断旧版本
exclude 的本质是干预 MVS 的候选集，不是魔法开关。它有效与否，取决于你的依赖图里是否真有“非它不可”的路径 —— 而这点，只有 go mod graph 和 go mod why 能说清。
