Go接口新增方法必须定义新接口名而非修改旧接口，JSON字段新增需用指针或omitempty，废弃字段不可删除而应保留并加json:"-"或改可空类型，Protobuf字段编号与类型严禁变更。
Go 接口不能直接新增方法——否则所有旧实现会立刻编译失败；字段新增必须用指针或 omitempty，废弃字段绝不能删，得留着并加 json:"-" 或改类型为可空。
接口新增方法会导致编译失败，必须换新接口名
Go 的接口是隐式实现的，只要结构体满足所有方法签名就自动实现该接口。一旦你在公开接口里加一个新方法，所有已有的实现代码立刻报错：missing method XXX。
实操建议：
- 不要修改原有接口，而是定义一个新接口，比如从
Runner扩展出RestRunner - 新接口可以嵌套旧接口：
type RestRunner interface { Runner; Rest() error }，复用已有契约 - 业务逻辑中用类型断言判断是否支持新能力：
if r, ok := obj.(RestRunner); ok { r.Rest() } - 避免在公共库中导出“大而全”的接口，优先按能力拆分（如
Reader、Writer、Closer）
JSON 字段新增：指针 + omitempty 是安全底线
旧客户端发请求时不含新字段，服务端若用值类型（如 int）接收，json.Unmarshal 会填零值（0），可能被误判为有效输入。
实操建议：
- 新增字段一律用指针：
UpdatedAt *time.Time `json:"updated_at,omitempty"` - 或用可空基础类型：
Status *string `json:"status,omitempty"` - 禁止写
json:",required"——Go 的encoding/json根本不识别这个 tag，写了等于没写 - 如果必须用值类型（如
Version int），就在 struct 初始化时显式设默认值，别依赖反序列化“猜”
字段废弃不能删，要留锚点做迁移和监控
直接删字段或加 json:"-" 看似“隐藏”，实则切断了新老协议之间的字段映射锚点。后续想加日志、校验、灰度开关都无从下手。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
- 废弃字段保留定义，仅加注释说明：
// Deprecated: use CreatedAt instead - 配合
json:"-"阻止序列化输出，但保留内存结构：OldField int `json:"-"` - 若需兼容旧客户端传该字段，就别加
json:"-"，改用可空类型并忽略其值 - 上线后通过日志统计该字段是否还被传入，确认下线时机
Protobuf 字段变更比 JSON 更敏感，编号和类型锁死
Protobuf 不是文本协议，字段编号直接对应二进制 wire format。改编号、改类型（如 int32 → int64）、删字段再重用编号，都会导致解码错位甚至 panic。
实操建议：
- 新增字段必须是
optional（v3 默认）或repeated，禁用required - 废弃字段用
reserved 5;占位，而不是直接删除 - 升级时启用
proto.UnmarshalOptions{DiscardUnknown: false}，检查XXX_Unrecognized字段长度，监控未知字段比例 - 确保
proto.RegisterFile和生成代码同步更新，否则 gRPC 反射、grpc-gateway 会失效
最容易被忽略的是：字段“看起来没变”，但类型从 int 改成 *int 或加了 omitempty，对旧客户端就是静默破坏——它发的 {"count": 0} 在新结构体里可能变成 nil，业务逻辑分支就偏了。兼容性不是“能跑”，是“旧请求每一字节都按预期落进正确位置”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
