go mod tidy 不删除 deprecated 模块，因其仅依据 import 和间接引用判断依赖，不识别元数据废弃标记；盲目删除 require 行可能导致构建失败或运行时 panic，应先用 go mod graph 和 go list -deps 确认未被实际加载，再考虑 replace + exclude 安全隔离。
模块已被标记 deprecated，但 go mod tidy 不删它
go mod tidy 不会因为上游模块在 GitHub 或 pkg.go.dev 上显示 deprecated 就自动移除它——它只看 import 是否存在、是否被间接引用，不读取元数据或文档标记。你看到的“已废弃”只是作者加的说明，Go 工具链完全无视。
直接删 go.mod 里的 require 行可能引发构建失败
看似没 import，但它可能是某个你依赖的库（比如 github.com/some/lib）拉进来的间接依赖，而该库尚未升级到不依赖它的新版本。盲目删除会导致：build failed: missing required module 或运行时 panic（尤其当它提供 init()、plugin 或嵌入式资源时）。
- 先查谁在用它：
go mod graph | grep deprecated-module-name - 再确认是否真没被加载：
go list -deps -f '{{if not .Standard}}{{.ImportPath}}{{end}}' ./... | grep deprecated-module-name - 如果输出为空，且你确定没用
//go:embed、//go:generate或plugin.Open加载它，才可考虑移除
更稳妥的做法是 replace + exclude 组合使用
不是删，而是“隔离”。这样既避免构建中断，又防止意外调用废弃逻辑：
- 用
replace指向一个空实现或最小 stub（比如建个本地./stub/deprecated-mod目录，只含go.mod和空doc.go），确保 import 能解析但不执行原逻辑 - 加
exclude防止别人通过其他路径意外拉进来：exclude deprecated-module-name v1.2.3（注意：exclude 仅对 go build / go test 生效，不阻止 go get） - 如果该模块已被 fork 并维护（如
github.com/forked-maintained/mod），优先用replace切过去，而非硬删
CI/CD 中必须验证 replace/exclude 是否生效
本地能过不代表 CI 安全。容易忽略的是：go mod verify 不校验 replace 后的路径内容，go.sum 里也不会记录 stub 模块的哈希。
- CI 脚本中加一步：
go list -m all | grep deprecated-module-name，预期输出应为deprecated-module-name v1.2.3 => ./stub/deprecated-mod - 运行
go build -mod=readonly ./...，强制拒绝任何未声明的依赖变更 - 若项目含测试文件或生成代码，需确保
go test ./...仍通过——废弃模块常被测试工具链隐式引用
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
