5.3 未知字段与往返保真

5.3 未知字段与往返保真

本节摘要：未知字段机制是兼容体系的司法保障——解码器把不认识的字段按原始字节存起来，重新序列化时原样回传。本节拆解它的存储形态与"往返保真"的验证方法，盘点三类会破坏保真的现实场景（旧版 proto3 运行时、深拷贝丢失、序列化中转剥除），并给出中转服务的加固清单。读完你应当能设计并验证一条无损中转链路。

本章收官：前两节讲"人不去破坏机制"，本节讲"机制如何保护数据"——它是新字段先到旧端、代理转发、多版本共存三种场景的共同底座。

未知字段的存在形态

解码器遇到不认识的 tag，按 wire type 算出载荷边界，把"tag+载荷"整段原始字节存进消息的专属容器。各语言的容器形态：Go 里是不可导出的 unknownFields 字节切片、Java 是 UnknownFieldSet、C++ 是内部字符串。重新序列化时，已知字段按定义输出，未知字段追加在后——逐字节原样回传。

有一个容易忽略的细节：未知字段的解析深度。多数实现把未知字段按"外层"保存——如果未知的是一个嵌套 message，保存的是它的整段字节而非解析后的结构。这意味着旧端无法读取未知嵌套消息内部的字段（哪怕内部某个编号它认识），因为它根本不知道那段载荷是 message。这个限制是合理的：wire type 2 的载荷也可能是 string 或 bytes，旧端无从判断，只有契约能裁决——而契约恰恰缺失。

往返保真：一个可以机器验证的性质

定义：一条消息经过"序列化→反序列化→再序列化"后，输出字节与输入语义等价（不要求逐字节相同，但已知字段值与未知字段内容必须无损）。验证它只需要一小段测试代码——以 Go 为例：

// 往返保真验证：旧 schema 的解码器 + 新 schema 的消息
func TestRoundTrip(t *testing.T) {
    raw := []byte{0x08, 0x96, 0x01, 0x50, 0x2A}  // 字段1=150，字段10=42（本schema不认识10）
    var m OldMessage
    if err := proto.Unmarshal(raw, &m); err != nil { t.Fatal(err) }
    out, err := proto.Marshal(&m)
    if err != nil { t.Fatal(err) }
    // 关键断言：字段10的 tag+载荷 42 必须出现在输出里
    if !bytes.Contains(out, []byte{0x50, 0x2A}) {
        t.Fatalf("未知字段丢失: %x", out)
    }
}
​

这段测试值得进每个中转服务的 CI：它把"未知字段保留"从文档承诺变成机器守护。注意断言写法——找的是 tag+载荷的字节序列（50 2A），不是值本身，因为未知字段在输出里的位置与顺序不保证。

三类破坏保真的现实场景

场景一：旧版 proto3 运行时的政策遗留。 第 1.2 节讲过，proto3 3.5 版本之前默认丢弃未知字段。存量系统里可能还有老 Java 服务跑在丢弃版本上——它们做中转时，所有未知字段被静默剥除。排查方法：对可疑中转节点做字节对拍（进出的十六进制对比，4.2 节的手法），剥除会直接现形。

场景二：深拷贝与序列化变体。 一些"优化"路径会绕过未知字段：比如某些框架做对象映射（proto 转 proto）时只复制已知字段，未知容器被落在原地。判断原则：任何"逐字段搬运"的代码都要显式处理未知字段，用语言运行时自带的 Clone/Merge 方法（它们保留未知字段）而不是手写复制循环。

场景三：序列化格式切换。 消息经过 proto→JSON→proto 的往返（第 8 章互操作话题）时，未知字段在 JSON 侧的存留取决于实现——proto3 官方 JSON 映射没有为未知字段定义位置，多数转换器直接丢弃。跨格式链路的设计要默认"未知字段到这里为止"。

图 5-4 中转链路的保真衰减点

中转服务的加固清单

网关、代理、sidecar 类服务的未知字段义务清单：

1. 永远使用官方运行时的 Unmarshal + Marshal，不手写字段搬运；
2. CI 里挂往返保真测试，输入样本里故意带"未来字段"（当前契约之外的编号）；
3. 升级节点做字节对拍：同一消息进出中转的前后十六进制对比，作为升级验收项；
4. 禁止在 JSON 往返后声称无损：跨格式转换的服务在文档里显式声明未知字段的终点。

实战案例：一次"新字段丢失"的链路排查

背景：第 9 章预告的微服务场景里，服务 A 新增了字段 21，服务 B（新契约）经过统一网关后偶发收不到该字段。直连（绕过网关）一切正常。操作：第一步在网关出入口各抓一条消息，十六进制对拍——出口消息里字段 21 的 tag+载荷消失，锁定网关。第二步查网关实现：它做了一次 proto→内部模型→proto 的字段搬运（为了做统一鉴权注入），手写搬运只复制已知字段。第三步改造：鉴权信息改走传输层头部，消息体用官方 Unmarshal 后原样 Marshal 转发，CI 加往返保真测试（样本含未来字段）。结果：字段丢失归零，网关升级流程里从此多一道字节对拍验收。解读：中转服务的常见架构错误是"顺手把消息体解开处理"——一旦解开，未知字段义务就转到你手上；能不动消息体就不动，要动就用带保真的运行时 API。变式：如果网关确实需要读取部分字段（如路由键），用第 6 章的反射机制按需读取而不整体解开重建，读取不改写，保真天然保持。

本节要点回顾

• 存储形态：未知字段按"tag+载荷"整段原始字节存进专属容器，重序列化时原样回传；
• 解析深度限制：未知嵌套 message 只存外层字节，内部字段即便编号认识也读不到；
• 往返保真可机器验证：一段含未来字段的样本 + 字节包含断言，进 CI 即成守护；
• 三类破坏点：3.5 前的旧运行时、手写字段搬运、跨 JSON 往返——中转链路逐个排查；
• 中转纪律：能不解消息体就不解；要解就用官方 Clone/Merge；跨格式即宣告保真终点。

分期体系完成。下一章进入更高阶的发掘：铭文释读——options、反射与动态消息，让契约里的元数据与运行时的类型信息系统开口说话。