exclude仅在当前模块生效，下游构建时完全无视该声明，因Go工具链只读取当前go.mod且不传播exclude指令，故无法帮下游规避被排除的版本。
go.mod 中的 exclude 为什么不影响下游
exclude 只在当前模块生效，下游模块构建时完全无视你的 exclude 声明。Go 工具链在解析依赖时，只读取当前模块的 go.mod，不会继承或传播 exclude 指令。
常见误解是：加了 exclude github.com/some/lib v1.5.0 就能“帮下游避开这个坏版本”。实际效果是：你本地构建绕过了 v1.5.0，但下游拉取你模块时，仍会按自己的 go.mod + MVS 算法重新计算依赖，v1.5.0 可能照常被选中——尤其当它的兼容性约束没被破坏时。
- exclude 的唯一作用是：阻止当前模块加载某个特定版本，哪怕它被间接 require
- 下游若也遇到该版本问题，必须自己写
exclude或升级上游依赖 - 如果某模块作者用
exclude隐藏了一个已知严重 bug 版本，下游无法感知，只能靠文档或手动排查
replace 对下游完全不可见
replace 是纯本地路径/版本重映射，仅影响 import 解析阶段，且不写入 go.sum 校验范围。下游模块的 go build 过程根本看不到你的 replace 规则。
典型错误场景：你在开发时写 replace github.com/some/lib => ./fix 调试通过，忘了删掉就提交。CI 构建失败，报错 cannot find module providing package github.com/some/lib——因为 CI 机器没有 ./fix 这个路径，且 replace 不传递。
立即学习“go语言免费学习笔记（深入）”；
- replace 后必须执行
go mod tidy，否则go.sum里缺校验和，远程构建直接失败 - 用
replace指向 fork 分支时，要确保 commit hash 在go.sum中存在，否则下游go get会卡在 checksum mismatch - 主版本升级（如 v2）必须同步改 import path，仅 replace 不足以解决 v1/v2 共存问题
撤销版本的真实手段只有两个：打新 patch 或发 deprecation notice
Go 生态不支持“服务器端撤回已发布版本”，exclude 和 replace 都是客户端干预手段。真正能让下游规避问题的，只有作者主动操作：
- 发布一个修复版（如 v1.5.1），并在 CHANGELOG 里明确标注 v1.5.0 有严重 bug
- 在模块 README 或 GitHub Release 页面写 deprecation notice，附带升级指引
- 若 v1.5.0 已造成广泛影响，可考虑用
retract（Go 1.16+ 支持），例如在 go.mod 中写retract v1.5.0，这会向 proxy 发送信号，让go list -m all显示该版本为 “retracted”，但旧版本依然可下载
retract 是目前最接近“撤销”的官方机制，但它不删除文件、不阻止下载，只提供语义提示——下游是否响应，取决于开发者是否运行 go get -u 或检查警告。
下游如何发现上游撤回或 exclude 信息
没有自动通知机制。下游只能靠三件事被动感知：
- CI 构建失败时看到
retracted提示（需 Go 1.16+ 且上游用了retract） - 手动执行
go list -m -versions github.com/some/lib，查看输出里是否有v1.5.0 (retracted) - 订阅上游仓库的 Releases 或 RSS，或定期跑
go list -m all | grep retracted
最容易被忽略的是：retract 不改变 MVS 结果，除非下游显式 go get 升级——它只是标记，不是强制拦截。
