Go模块弃用需以go.mod中// Deprecated:注释为准，格式为紧贴module声明后单行注释；可靠识别方式是go list -m -u all输出含(deprecated)标记或go get提示弃用，其他如版本号、归档状态均不可靠。
如何识别一个 Go 模块已被弃用
Go 官方不提供统一的“弃用标记”机制，但模块作者可通过 go.mod 文件中的 // Deprecated: 注释或仓库 README 显式声明。真正可靠的信号是：go list -m -u all 输出中带 (deprecated) 标记的模块，或 go get 提示 “module github.com/xxx/yyy is deprecated”。注意：仅靠版本号（如 v0.x）或 GitHub 仓库 archive 状态不能作为弃用依据，必须以 go list 或模块作者在 go.mod 中的明确注释为准。
go.mod 里怎么写弃用声明才被 go tool 识别
必须在模块根目录的 go.mod 文件末尾添加形如 // Deprecated: use github.com/xxx/newlib instead 的单行注释，且该注释需紧贴模块声明之后、require 块之前。例如：
module github.com/old/lib // Deprecated: use github.com/new/lib instead go 1.21
其他位置（如注释在 require 块内、多行注释、空行隔开）均不会被 go list 或 go get 解析为弃用声明。工具链只认这种严格格式。
迁移时为什么不能直接 replace + go mod tidy
直接在 go.mod 中写 replace github.com/old/lib => github.com/new/lib v1.0.0 再执行 go mod tidy 很容易失败，原因有三：
立即学习“go语言免费学习笔记（深入）”；
-
new/lib的 API 可能完全不兼容，tidy不会检查代码是否能编译，只管依赖图收敛 - 如果
old/lib被多个间接依赖引用，replace会全局生效，可能破坏其他依赖的预期行为 -
go.sum中旧模块的校验和仍保留，而新模块未被校验，go mod verify会失败
正确做法是先手动改代码、删掉所有对 old/lib 的 import 和调用，再 go mod tidy 清理旧依赖；最后才引入 new/lib 并适配新 API。
弃用模块的依赖还在项目里，但没被 import，要不要删
要删，但不能靠肉眼判断。运行 go mod graph | grep old/lib 查看是否仍有路径引用它；更可靠的是 go mod why github.com/old/lib —— 如果输出 (main module does not need github.com/old/lib)，说明它只是残留，可安全执行 go mod tidy 移除。遗留的弃用模块会污染 go.sum、拖慢 go list、干扰 CI 的依赖扫描，且 Go 1.22+ 已开始对未使用弃用模块发出 warning。
弃用声明不是通知，而是契约；工具链只响应特定格式的注释，而迁移成败取决于代码层适配，不是依赖替换命令本身。
