最稳妥的做法是在结构体开头加 uint8_t version 并配合握手协商，新解析器先读版本号再查表调用对应解析函数，发送前必须通过握手包同步双方支持的最小版本，否则协议版本无效。
怎么在协议头里塞版本号又不影响老代码
直接在结构体开头加 uint8_t version 是最稳妥的做法，但必须保证老版本数据能被新解析器“跳过”或“识别为旧版”。不能把版本号塞在中间或末尾——那样会导致 offsetof 偏移错乱，老代码按旧结构体读内存会直接越界或解错字段。
- 所有协议结构体统一用
#pragma pack(1)（或__attribute__((packed))），否则编译器对齐填充会让版本号位置不可控 - 新解析器先读前 1 字节判断
version，再决定用哪套struct或解析逻辑分支 - 老版本数据（version=0）进新服务时，不能直接 memcpy 到新版结构体——要显式字段拷贝，避免未初始化字段残留垃圾值
解析函数怎么写才不爆栈、不漏版本分支
别写一个大 switch 把所有版本的完整解析逻辑全塞进去。版本一多，函数膨胀、维护困难，还容易漏掉某个版本的某字段默认值处理。
- 用函数指针表：定义
static const parse_func_t g_parsers[] = {parse_v1, parse_v2, parse_v3};，根据version查表调用 - 每个
parse_vX只负责本版本的字段提取和校验，共用的校验（如包长、CRC）提到公共函数里 - 如果某字段在 v2 加入、v3 废弃，不要在 v3 解析函数里留着它——留着就可能误读后续字段；宁可加个
unused[4]占位
序列化时怎么避免版本升级后发错包
发送端不检查对方支持什么版本，只按自己当前协商/配置的 protocol_version 打包。但关键点在于：**发包前必须确认双方已同步版本**，否则接收方根本不知道该用哪个解析器。
- 连接建立阶段必须走握手包（比如
HandshakeReq/HandshakeResp），里面带client_version和server_version，协商出 min(双方支持的最高版本) - 禁止在握手完成前发业务包；否则收到的包会被当成 garbage —— 因为接收方还在用默认 v0 解析器等着
- 如果服务端只支持 v1/v2，客户端发 v3 包，
HandshakeResp应返回错误码而非静默降级，防止语义错乱
为什么 protobuf 不是万能解法
protobuf 的 backward/forward compatibility 确实省心，但真实嵌入式或高性能场景下，它带来的序列化开销、内存分配、反射成本经常不可接受。而且——它没法解决「字段语义变更」问题。
立即学习“C++免费学习笔记（深入）”；
- 比如 v1 的
timeout_ms到 v2 改成timeout_ns，proto 只能靠注释约定，运行时无法校验单位是否被误用 - 二进制兼容 ≠ 行为兼容。v2 加了个新字段用于限流策略，但老客户端没填，服务端若没设默认值就会 crash 或逻辑异常
- 真正需要的是：协议版本 + 显式解析路径 + 握手协商。protobuf 只帮你做了前半截
