//go:build 和 // +build 不影响 require 覆盖逻辑；replace 和 exclude 仅作用于模块图构建阶段，与源码构建约束无关；exclude 不阻止间接依赖引入，仅禁止指定版本参与版本选择，且对 indirect 依赖无效。
go.mod 中 //go:build 和 // +build 不影响 require 覆盖逻辑
Go Modules 的 replace 和 exclude 只作用于模块图构建阶段，和源码中的构建约束完全无关。你加了 //go:build ignore 或在文件头写 // +build !amd64，不会让 go build 跳过该模块的依赖解析——只要它出现在任何被 import 的路径里，就会进模块图。
常见错误现象：go list -m all 仍列出被 exclude 的模块，但实际编译时却报错说“找不到符号”，其实是另一个未被 exclude 的间接依赖偷偷拉进了冲突版本。
-
exclude不是“忽略导入”，而是“禁止该模块版本参与版本选择” - 如果某模块被多个路径间接引入，且其中一条路径绕过了
exclude（比如通过replace指向了 fork 分支），exclude就失效 -
go mod graph是唯一能验证exclude是否真正生效的命令
exclude 对 indirect 依赖无效
当你看到 go.mod 里某行带 // indirect 标注，说明这个模块没被你的代码直接 import，而是被其他依赖拖进来的。这时候加 exclude 很可能白忙活。
使用场景：你想降级某个底层库（比如 golang.org/x/net），但它被 google.golang.org/grpc 强依赖，而你又没直接 import x/net —— 此时 exclude 无法阻止 grpc 自己选版本。
- 先运行
go mod graph | grep 'golang.org/x/net'看谁在拉它 - 若发现是
grpc@v1.60.0强绑定x/net@v0.23.0，那得改replace golang.org/x/net => ...，而不是exclude -
exclude只对“可被选中但你不想要”的模块起效，对“必须锁定”的间接依赖无权否决
exclude 和 replace 同时存在时的优先级陷阱
如果同一个模块既被 exclude 又被 replace，Go 工具链会静默忽略 exclude —— 因为 replace 已经把原始模块名映射到另一个路径，exclude 的目标模块名已不存在于模块图中。
错误现象：go mod tidy 后 go.mod 里 exclude 行还在，但 go list -m golang.org/x/text 显示的却是你 replace 过的 fork 版本，仿佛 exclude 没生效。
-
replace发生在模块路径重写阶段，exclude发生在版本裁剪阶段，前者早于后者 - 想彻底屏蔽某个模块？删掉所有
replace它的语句，再确认exclude是否覆盖全部引入路径 - 用
go mod edit -dropreplace=xxx可批量清理 replace，比手动删更安全
CI 中 go mod verify 失败但本地正常？检查 exclude 是否漏掉子模块
exclude 只匹配模块路径全等，不支持通配符或前缀匹配。如果你 exclude 了 example.com/lib@v1.2.0，但某依赖实际 import 的是 example.com/lib/encoding@v1.2.0，那这个子模块完全不受影响。
性能影响：这类漏掉的子模块可能带来重复符号、类型不兼容或测试失败，尤其在跨平台 CI（如 macOS vs Linux）上表现不一致，因为不同系统下 go list 解析 vendor 或 cache 的行为略有差异。
- 运行
go list -deps -f '{{.Module.Path}}' ./... | grep 'example.com/lib'找出所有实际被引用的子路径 - 每个子路径都要单独
exclude，例如exclude example.com/lib/encoding v1.2.0 - 没有“排除整个域名”这种操作，Go Modules 的模块粒度就是
module path，不是域名
