使用 json:"-,omitempty" 会导致字段完全不出现在 json 中，服务端反序列化时填零值而非 nil，引发空指针或逻辑错误；正确做法是保留字段、移除 omitempty、改用可空类型或显式初始化默认值。
Go struct 字段加 json:"-,omitempty" 为什么旧客户端一调就 panic？
因为这不是“废弃字段”的正确做法。它会让字段彻底不出现在 JSON 中，但服务端反序列化时若该字段非指针且无默认值，json.Unmarshal 会直接填零值（比如 0、""、false），而业务逻辑可能依赖其为 nil 或显式未设置——结果就是空指针或逻辑错判。
- 真正要表达“该字段已废弃但需保持向后兼容”，应该保留字段，仅去掉
jsontag 中的omitempty，并确保类型是可空的（如*string、map[string]interface{}） - 如果字段必须是值类型（如
int），就在 struct 定义里显式初始化默认值：Version int `json:"version"`→Version int `json:"version"`并在构造时设为1，而非靠反序列化“猜” - 别用
json:"-"或json:"-,"：这会让旧字段完全消失，新老协议之间失去字段锚点，后续想加校验或迁移逻辑都无从下手
RPC 接口升级时，如何让新字段不破坏旧客户端？
关键不是“加字段”，而是“加字段 + 控制反序列化行为”。Go 的 encoding/json 和 gob 默认都允许未知字段存在，但 protobuf（尤其 google.golang.org/protobuf）默认会报错：proto: unknown field "xxx"。
- 对 JSON RPC：只要新字段有
jsontag 且类型可零值化，旧客户端发包不含该字段，服务端反序列化后字段就是零值，不会 panic —— 前提是业务代码能容忍这个零值（比如用if req.NewField != nil判断） - 对 Protobuf：必须在
UnmarshalOptions中启用DiscardUnknown：proto.UnmarshalOptions{DiscardUnknown: true}，否则任何未知字段都会导致整个请求失败 - 别在 proto 文件里删字段再重编号：这是最危险的操作，gRPC 客户端缓存 descriptor 后可能把新字段当旧字段解析，数据错位
json.Marshal 输出字段顺序乱了，影响签名或缓存一致性？
Go 的 json.Marshal 不保证字段顺序，底层用的是 map 遍历，而 map 是随机迭代的。如果你在做请求体签名、HTTP 缓存 key 计算、或者和 Java/Python 服务联调要求字段顺序一致，这就成了隐性坑。
- 不要依赖 struct 字段声明顺序：它和 JSON 输出顺序无关
- 真需要确定顺序，用
map[string]interface{}手动控制键顺序，或引入第三方库如github.com/mailru/easyjson（支持easyjson:"order=1"tag） - 更稳妥的做法是：签名/缓存逻辑不基于原始 JSON 字符串，而是基于规范化的字段名+值对列表（如按 key 字典序排序后拼接），避免被序列化实现细节绑架
字段标记 deprecated 注释，Go 能自动警告调用方吗？
不能。Go 原生不解析 struct tag 或注释里的 // deprecated，go vet 也不管这个。所谓“废弃提示”全靠人肉看文档或 IDE 插件（比如 GoLand 可识别 // Deprecated: 注释并标灰），对 RPC 接口调用方毫无约束力。
立即学习“go语言免费学习笔记（深入）”；
- 真正的兼容性保障不在注释，而在运行时行为：字段保留、不 panic、返回合理默认值、日志打点记录旧字段访问（如
log.Printf("legacy field 'OldParam' used")） - 如果想推动客户端升级，可在响应中加
X-Deprecated-WarningHTTP header，或在 RPC 返回的ResponseMeta里塞提示字段，但别指望它自动生效 - 最狠但有效的办法：上线灰度期后，在服务端对访问已废弃字段的请求返回
410 Gone或自定义错误码，逼客户端改——前提是监控到位、降级方案明确
字段废弃不是删代码，是留门、设防、记日志、给退路。最容易被忽略的是：没在反序列化前做字段存在性检查，也没在业务逻辑里区分“用户没传”和“用户传了零值”。这两者语义完全不同，但 Go 的 struct 零值机制会让它们看起来一模一样。
