go中识别废弃api需主动检查服务端返回的状态码（如410、426）、响应头（x-deprecated-by）、json字段（deprecated:true）及未知字段错误；客户端须在http层拦截、结构体解析替代map、添加废弃守卫与兼容性处理。
Go 里怎么识别调用的是已废弃的 API？
废弃 API 本身不会自动报错，关键看服务端是否返回明确标识——比如 HTTP 状态码 410 Gone、426 Upgrade Required，或响应体里带 "deprecated": true 字段。客户端不检查这些，就永远“感觉不到”它被弃用了。
常见错误现象：接口突然返回空数据、500、或字段缺失，但日志里没报错，调试半天才发现是服务端悄悄下线了旧版路由。
- 务必在 HTTP 客户端层统一检查状态码，尤其是
410和426，别只盯着2xx和5xx - 如果响应是 JSON，反序列化前先读取顶层字段（如
api_version或deprecation_notice），用json.RawMessage做轻量预检 - 不要依赖文档“记得更新”，把废弃提示写进响应头，比如加
X-Deprecated-By: /v2/users，Go 客户端用resp.Header.Get("X-Deprecated-By")就能直接拿到迁移路径
用 interface{} 接口升级时 panic: interface conversion 是怎么回事？
老代码用 map[string]interface{} 解析响应，新版 API 改了字段类型（比如 "count" 从 float64 变成 int64），但 Go 的 json.Unmarshal 默认全转成 float64，你强转 int 就 panic。
这不是类型系统的问题，是 JSON 解析策略和预期不一致。
立即学习“go语言免费学习笔记（深入）”；
- 别对
interface{}做裸断言，先用fmt.Printf("%T", v)看实际类型 - 用结构体替代
map[string]interface{}，哪怕只定义几个关键字段，也能让json包按需转换 - 如果必须用泛型 map，转型时加类型检查：
if f, ok := v["count"].(float64); ok { count = int(f) }，而不是直接v["count"].(int)
如何让旧版调用快速失败，而不是静默降级？
静默降级（比如旧 API 返回空数组，新 API 要求非空）最危险——业务逻辑照常跑，问题拖到下游才暴露。得让错误浮到表面。
核心思路：在 client 层加一层“废弃守卫”，不是等 panic 或业务校验失败，而是主动拦截。
- 给每个废弃 endpoint 配一个
DeprecatedRoute注册表，含路径、生效时间、推荐替代路径 - HTTP client middleware 中检查
req.URL.Path是否命中废弃路由，命中则立即返回自定义 error：errors.New("api deprecated: use /v2/users instead") - 这个 error 要带可检索关键词，比如前缀
DEPRECATED:，方便日志聚合和告警（grep "DEPRECATED:" logs） - 别用
log.Fatal或 panic，error 要能被上层if err != nil捕获并处理
gRPC 接口升级后，老 client 调用新 server 报 unknown field 错误
Protobuf 升级时加了新字段但没设默认值，或用了 optional 但老 client 生成的代码不识别，就会在反序列化时卡住，报 proto: unknown field "xxx"。
这跟 JSON 不同，protobuf 更严格，且错误发生在底层 unmarshal 阶段，连 handler 都进不去。
- 所有新增字段必须加
optional（proto3）或设默认值（proto2），并确保go_package版本与生成代码一致 - server 端启用兼容模式：用
grpc.WithDisableRetry()配合自定义UnaryServerInterceptor，捕获status.Code() == codes.Internal且消息含"unknown field"时，改写为更友好的 error - client 端升级前，用
protoc-gen-go生成新 stub 时加--go-grpc_opt=paths=source_relative，避免 import 路径错乱
废弃不是删掉就完事，是让调用者在出问题前就知道要改什么。最难的不是写新接口，是让旧调用在日志里留下足够线索——字段名、路径、时间戳、推荐方案，缺一不可。
