完整课程入口：996 全套课程体系 ｜ Lua 学习路径 ｜ 幂尔框架 mirs.cn
Protobuf 解码需要把字节流还原成完整对象树，消息越大解码耗时越长。FlatBuffers 的卖点是零拷贝：数据按"可直接读取"的布局写入，使用时不构造对象、按字段偏移直接取值。对高频大幅数据（排行榜全量快照、场景实体同步）这是值得评估的选项；小消息场景差异可忽略。
Protobuf：编码小、字段兼容性好，但读取前必须整体 decode 成对象表。FlatBuffers：编码体积略大（对齐填充），读取零拷贝、随机访问单字段 O(1)。Lua 绑定方面：Protobuf 有成熟的 pb 库；FlatBuffers 官方也提供 Lua 代码生成，但生态与文档明显少，接入成本高一级。
测试样本：排行榜快照 1000 条（id、名字、积分、排名），各序列化与读取 100 次取平均（LuaJIT 2.1 环境）：
| 指标 | Protobuf | FlatBuffers |
|---|---|---|
| 编码耗时 | 14ms | 19ms |
| 全量读取 | 22ms | 3ms |
| 单字段随机读 | 需先全量 decode | 0.004ms/字段 |
| 编码体积 | 86KB | 104KB |
结论直接从数据里读出来：需要"读全量"时两者接近，需要"频繁随机读单字段"（如客户端分帧刷新排行榜）时 FlatBuffers 的零拷贝优势是数量级的。
决策树三步：消息体小于 4KB 或读取频率低 → Protobuf（生态成熟、调试方便）；大快照 + 高频随机读 → FlatBuffers；两端都要维护且人手紧张 → 统一 Protobuf 降低学习成本。混合使用也是常见方案：常规协议走 Protobuf，只有排行榜与场景同步两三个大消息走 FlatBuffers。无论选哪个，schema 只加不改的纪律不变——序列化格式换了，兼容纪律不换。
FlatBuffers 的 Lua 代码生成需要图谱工具链配合（flatc 编译 schema 生成绑定），版本升级时生成代码要同步重生成，手工改生成文件会在下次重生成时丢失。接入前评估团队维护意愿：能用 Protobuf 覆盖的场景，引入 FlatBuffers 的维护成本要计入决策。