Protobuf3跨多设备通信时uint32、uint64数据类型适配问题咨询

分运行平台差异如下：

• 移动端（Android/iOS）：Dart runtime使用64位有符号整数实现，protobuf的uint64默认映射为Dart的int类型，和Kotlin/Java逻辑一致，仅能安全承载0~9223372036854775807范围的取值，超过该范围的无符号值会被解析为负数。
• Web端：Dart编译为JavaScript后，int底层是JS双精度浮点数，最大安全整数为2^53 - 1（即9007199254740991），超过该值的整数会出现精度丢失。

是的，只要你的链路包含Kotlin/Flutter移动端/Java这类默认将无符号64位整数映射为有符号64位整数的语言环境，整个系统的uint64有效取值只能限定在0~9223372036854775807区间，除非做特殊的二进制编码处理。

你可以根据业务容错要求选择以下两种方案：

方案1：保留现有proto定义，各端做无符号语义转换 #

uint32的0_{4294967295全范围二进制存储，刚好对应有符号32位整数的-2147483648}2147483647区间，各端仅需要做简单的数值转换即可保证语义正确：

• Kotlin端：解析得到Int值后调用toUInt()方法，即可得到0~4294967295范围的无符号值；序列化时直接传入UInt类型，或调用toInt()转成有符号Int传入protobuf接口即可，二进制存储完全一致不会出错。
• Python端：protobuf解析得到的int本身支持全范围无符号32位值，无需额外处理，序列化时只要保证传入值在0~4294967295区间即可。
• Flutter端：移动端解析得到的int值调用toUnsigned(32)即可得到正确的无符号32位值；Web端由于2^32小于JS最大安全整数，不会出现精度丢失，直接转换即可。
• C/C++端：无需修改，直接按uint32_t类型使用即可。
  该方案的优势是无需修改现有proto定义，传输效率无损失。

方案2：修改proto定义消除跨端语义歧义（更推荐） #

如果担心各端转换遗漏导致问题，可以直接调整CRC32字段的类型，彻底避免类型语义差异：

syntax = "proto3";

message Request{
    uint64 serial_number;
    // 方案2a：使用fixed32类型，传输效率和uint32一致，无符号语义更明确
    fixed32 checksum;
    // 方案2b：使用bytes类型存储4字节CRC值，完全避免类型转换问题，适合容错要求极高的场景
    // bytes checksum = [字段编号];
}

既然你确认序列号不会达到2^63-1的上限，仅需要在各端增加简单的取值校验即可：

• C/C++端：生成序列号时限制最大值不超过9223372036854775807
• 其余各端：解析后校验序列号大于等于0，避免负数进入业务逻辑
  如果未来确实需要用到uint64全范围取值，可以将字段修改为bytes类型存储8字节原始值，各端自行做编解码即可。

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