Go编译器默认不因//go:deprecated中断构建，仅输出警告；警告只在调用处触发，且仅对导出标识符生效；可通过staticcheck -checks 'SA1019'将其转为硬性错误。
编译时看到“xxx is deprecated”警告，但没报错
这不算错误，Go 编译器默认不因 //go:deprecated 中断构建，但会输出警告。IDE（如 VS Code）、go vet 或 CI 中启用 -gcflags="-d=printdeprecated" 时可能放大提示，容易误判为失败。
常见场景：调用了一个带 //go:deprecated 注释的导出函数（如 http.ListenAndServe 被标记后，你代码里还直接用了它），或依赖的第三方库升级后废弃了某个接口，而你的代码还没适配。
- 只有首字母大写的导出标识符（如
OldClient）加了//go:deprecated才会触发警告；oldClient()这类私有函数加了也无效 - 警告只在「调用处」出现，不是定义处——删掉调用，警告自然消失
-
go build默认忽略它；go test也不会因它失败，除非你显式加了-vet=shadow等额外检查
怎么让 deprecated 警告变成硬性错误
如果你希望强制拦截，比如在 CI 中禁止使用已废弃 API，就得主动干预。Go 本身不提供 -Werror=deprecated 这种开关，但有可行路径：
- 用
go vet -vettool=$(which staticcheck)配合staticcheck工具，它能把SA1019（deprecated usage）当作 error 处理 - CI 中加一行：
staticcheck -checks 'SA1019' ./... || exit 1，只要发现废弃调用就中断构建 - 别依赖
go build -gcflags="-d=printdeprecated"——它只打印，不退出，无法用于门禁
为什么删了调用，警告还在
不是缓存问题，而是 import 或间接引用残留。典型情况：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 你删了
OldHelper()调用，但还留着import "github.com/example/lib"，而该包内部 init 函数或全局变量引用了废弃符号，导致链接期仍触发警告 - 依赖链中某中间包（比如 A → B → C）调用了废弃 API，你没直接调，但
go list -m all显示 C 在依赖树里，且它没升级 - IDE 缓存未刷新：VS Code 里按
Ctrl+Shift+P→ “Go: Restart Language Server”，JetBrains 点 “File → Reload project”
替换废弃 API 时最常踩的坑
官方文档或注释里写的替代方案（如 "use NewHelper(ctx) instead"）看似明确，实操时容易掉进语义陷阱：
- 新函数可能要求非空
context.Context，但你传了nil或context.Background()后行为异常——得看新函数是否对 cancel/timeout 有强依赖 - 返回值类型变了：旧版返回
error，新版返回(Result, error)，漏解包会导致静默逻辑错误 - 新函数是泛型，调用时没写类型参数（如
NewMap[string, int]()），编译报错位置会指向调用行而非定义行，迷惑性很强 - 别在
init()函数里调用新版 API——如果该文件被//go:build !go1.21排除，但 import 语句还在，init 仍会执行并 panic
真正麻烦的不是找到警告，而是确认所有间接依赖都已同步升级。一个 go mod graph | grep old-package 比盯着 warning 日志更管用。
