为何Protocol Buffer仅支持非空值类型使用打包特性？

先把概念理清楚：你说的repeated int32用的Tag-Value其实是打包（packed）序列化的简化说法，准确结构是Tag-Len-[Value1, Value2,...]——把整个数组当成一个连续块来序列化；而repeated message只能用非打包序列化，也就是每个元素单独带Tag-Len-Value结构。

这种差异设计的核心原因，说到底是值类型和消息类型的本质区别，具体拆成三点：

1. 空值处理的天然差异 #

• 像int32、bool这类基础值类型，本身是没有空值概念的——你没法定义一个“null的int32”，数组里的每个元素都是有效的值。打包后只靠长度字段就能算出元素数量，不会有歧义。
• 但message类型不一样：Protobuf里的message字段可以是“未设置”状态（逻辑上等价于null）。如果给repeated message用打包模式，根本没法区分“数组里有一个未设置的message”和“数组少了一个元素”，非打包模式下每个元素都单独带标签，能明确标记每个存在的实例，自然兼容这种可选状态。

2. 性能与灵活性的权衡 #

• 打包模式对基础值类型来说是纯优化：减少重复标签的字节开销，序列化后的数据更小，反序列化时一次性读整块数据也更快。但这种优化只在无空值的场景成立——要是允许空值，打包的块结构会变得模糊，反而要加额外判断，得不偿失。
• 消息类型本身结构复杂，每个实例的长度都不固定，强行打包的话，没法用一个统一的长度字段把所有元素包起来（总长度不好算），反而不如每个元素单独带标签和长度灵活。而且早期Protobuf版本也不支持消息的打包序列化，这种设计也兼顾了兼容性。

3. 语义一致性的要求 #

Protobuf的设计一直追求语义明确：

• 基础值类型的repeated字段，语义就是“一组连续的、非空的有效值”，打包模式完美匹配这个语义，不会产生误解。
• 消息类型的repeated字段，语义是“一组可选的消息实例”，每个实例是否存在是独立的，非打包模式的逐个标记正好对应这种独立语义，能准确还原原始的字段状态。

源码里那句“only non-nullable value types support packing”，本质就是把上面三点揉在一起的结论——只有当类型本身不存在空值歧义时，打包模式的优势才能发挥，同时不会搞乱语义。

内容的提问来源于stack exchange，提问作者Rider