紧凑型跨平台字节码序列化协议的核心是固定字节长度类型、显式协议级类型定义、严格字段顺序排布、1字节消息ID标识、长度前缀+紧凑块处理变长/可选字段，实现零开销二进制流。
直接利用基本数据类型在内存中占用固定字节长度这一特性，是设计紧凑型跨平台字节码序列化协议的核心出发点。关键不在于“能不能”，而在于“怎么对齐、怎么标记、怎么跳过冗余”。只要协议双方约定好字段顺序、类型编码和字节序（如小端），就能绕过 Schema 描述、字段名字符串、类型反射等开销，生成纯二进制流。
明确每种基础类型的确定字节数
不同语言对同一类型的实际字节长度可能不同（如 C 的 int 在不同平台可能是 4 或 8 字节），因此协议必须显式定义“协议级类型”，而非依赖语言默认：
- uint8 → 固定 1 字节（0–255）
- int32 → 固定 4 字节，小端序（LE）
- float64 → 固定 8 字节，IEEE 754 双精度
- bool → 单字节 0x00 或 0x01，不压缩为 bit 位（避免位运算跨平台歧义）
- string_len_prefixed → 先写 uint32 表示长度，再写 UTF-8 字节流（无 null 终止符）
结构体按字段顺序线性排布，禁用自动填充
结构体内存布局受编译器对齐策略影响，但协议字节码必须消除这种不确定性。做法是：所有字段严格按 proto 定义顺序拼接，不插入 padding 字节。例如：
// 协议定义 Person 结构（无版本/魔数，仅纯数据）uint32 id
uint8 age
uint32 name_len
byte[name_len] name_bytes
int32 score
该结构总长 = 4 + 1 + 4 + name_len + 4，完全可预测。接收方按此偏移逐段读取，无需解析字段名或类型名。
用紧凑标识替代类型名和字段名
不存 "id"、"name" 这类字符串，也不用 Protobuf 的 tag 编号（虽轻量但仍有 1–2 字节变长开销）。更进一步的做法是：整个消息头部用 1 字节协议 ID 区分消息种类（如 0x01=Person, 0x02=Order），后续字节全部按预设结构解释。这样连字段级元信息都省了，适合高频、低延迟场景（如游戏状态帧、传感器采样包）。
处理变长与可选字段的轻量方案
真正挑战在于变长字段（如数组、嵌套结构）和可选字段。不要用 flag 字节+条件跳转，而是采用「长度前缀 + 紧凑块」模式：
- 数组：先写 uint32 长度 N，再连续写 N 个固定长度元素（如 N×4 字节 int32）
- 可选字段：统一用“存在标志位”——每个可选字段对应 1 bit，所有标志打包成 1 字节（最多支持 8 个可选字段）；之后只序列化被标记为 true 的字段，按定义顺序排列
- 嵌套结构：将其视为内联字节块，长度前缀 + 内容，不引入嵌套层级标识
这种设计让字节流保持线性、无分支、无查找表，C/Go/Rust 等语言可零拷贝映射（unsafe pointer cast）到结构体指针，Java/C# 则通过 ByteBuffer 或 Span<byte> 手动偏移读取。
