【网络通信】FlatBuffers 对比 Protobuf：零拷贝序列化的取舍实测

实战应用：用在哪里

Protobuf 解码需要把字节流还原成完整对象树，消息越大解码耗时越长。FlatBuffers 的卖点是零拷贝：数据按"可直接读取"的布局写入，使用时不构造对象、按字段偏移直接取值。对高频大幅数据（排行榜全量快照、场景实体同步）这是值得评估的选项；小消息场景差异可忽略。

两种序列化的核心差异

Protobuf：编码小、字段兼容性好，但读取前必须整体 decode 成对象表。FlatBuffers：编码体积略大（对齐填充），读取零拷贝、随机访问单字段 O(1)。Lua 绑定方面：Protobuf 有成熟的 pb 库；FlatBuffers 官方也提供 Lua 代码生成，但生态与文档明显少，接入成本高一级。

实测数据

测试样本：排行榜快照 1000 条（id、名字、积分、排名），各序列化与读取 100 次取平均（LuaJIT 2.1 环境）：

结论直接从数据里读出来：需要"读全量"时两者接近，需要"频繁随机读单字段"（如客户端分帧刷新排行榜）时 FlatBuffers 的零拷贝优势是数量级的。

选型建议

决策树三步：消息体小于 4KB 或读取频率低 → Protobuf（生态成熟、调试方便）；大快照 + 高频随机读 → FlatBuffers；两端都要维护且人手紧张 → 统一 Protobuf 降低学习成本。混合使用也是常见方案：常规协议走 Protobuf，只有排行榜与场景同步两三个大消息走 FlatBuffers。无论选哪个，schema 只加不改的纪律不变——序列化格式换了，兼容纪律不换。

FlatBuffers 的 Lua 代码生成需要图谱工具链配合（flatc 编译 schema 生成绑定），版本升级时生成代码要同步重生成，手工改生成文件会在下次重生成时丢失。接入前评估团队维护意愿：能用 Protobuf 覆盖的场景，引入 FlatBuffers 的维护成本要计入决策。

本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付，内容以官方知识库与真实项目为出处，按版本持续修订。