为何Node.js中gRPC传输整数数组比REST HTTP API慢很多？

问题核心原因 #

你遇到的性能差异本质是Node.js生态下gRPC默认编解码实现的特性差异，和Protobuf协议本身的设计无关，具体可以拆解为三点：

1. 数字数组场景的开销差距来源

• Node.js官方gRPC库默认使用protobuf.js做编解码，大部分逻辑是纯JS实现的。对于repeated int32类型的字段，编解码时需要遍历数组每个元素做变长编码、类型校验，JS层的循环开销会随着数组元素数量上升呈线性增长，当数组规模达到百万级时，这个开销会远高于传输本身的耗时。
• 反观REST使用的JSON序列化/反序列化，是V8引擎原生C++实现的，对数字数组的处理做了大量底层优化，同等数据规模下的执行效率远高于纯JS实现的Protobuf编解码。
• 大数组编解码过程中会生成大量临时对象，频繁触发GC暂停，就是你观察到gRPC耗时波动大的核心原因。

2. 字符串场景gRPC反超的原因

• Protobuf的string字段编解码逻辑非常轻量，直接读写UTF-8字节序列即可，不需要逐个字符处理，即使是超大字符串也只有一次内存拷贝的开销。
• REST的JSON序列化需要对字符串做转义处理、前后加双引号，序列化后的载荷体积比Protobuf大30%以上，传输+序列化的总开销自然高于gRPC。

3. 优化建议

• 优先把数字数组改为bytes类型传输：发送端直接将JS数组转为Uint32Array再导出为Buffer，接收端直接从bytes字段读Buffer转回TypedArray，跳过逐个元素的编解码步骤，性能可以提升5~10倍。
• 显式给repeated int32字段加上[packed = true]配置（proto3默认开启，但部分旧版本实现可能未兼容），连续存储的数组可以减少字段头的额外开销。
• 换用C++实现的Protobuf编解码库，替换默认的protobuf.js，可以大幅降低大数组的编解码开销。

内容的提问来源于stack exchange，提问作者J.F.