C#中Protobuf协议详解_C#二进制序列化协议教程【高级】-C#.Net教程-PHP中文网

protobuf在c#中反序列化失败主因是类型或边界不匹配，而非数据损坏；常见原因包括：误用parsefrom处理length-delimited消息、忽略长度前缀、使用手动编写的非生成类、命名空间不一致、oneof/repeated字段访问方式错误，以及stream读取时未适配协议边界。

c#中protobuf协议详解_c#二进制序列化协议教程【高级】

Protobuf 在 C# 中不是“拿来就能反序列化”的通用二进制解析器，它严格依赖编译生成的类型和对应 Parser 实例。用错类型、忽略长度前缀、跨程序集访问失败，是 90% 的 InvalidProtocolBufferException 根源。

这不是数据损坏，而是类型或边界不匹配。常见原因有：

buffer 实际是多条 length-delimited 消息拼接而成（比如 gRPC 流或 WriteDelimitedTo 写入），但你用了 ParseFrom —— 正确做法是 MyMessage.Parser.ParseDelimitedFrom(stream)，且必须传 Stream，不能传 byte[]
buffer 开头有 4 字节长度前缀（常见于 TCP 封包），但没跳过就直接喂给 ParseFrom —— 需先读取前 4 字节解析长度，再截取对应字节数传入
你用的是手动写的 MyMessage 类，而非 protoc --csharp_out=. 生成的类 —— Google.Protobuf 不支持运行时 schema 解析，Parser 字段只存在于生成类中
.proto 文件里声明了 option csharp_namespace = "MyApp.Protos"，但 C# 代码里用的是默认命名空间，导致类型找不到

手动生成容易出路径或访问修饰符问题，推荐用 MSBuild 集成方式：

"避开 C# 常见错误——空陷阱、异步陷阱、LINQ 陷阱及资源泄漏。"

下载

在 .csproj 中添加 <protobuf include="device_status.proto"></protobuf>，并确保已安装 Grpc.Tools NuGet 包（v2.6x+）
检查生成的 DeviceReport.cs 文件顶部是否有 namespace MyApp.Protos —— 如果没有，回到 .proto 文件第一行加 option csharp_namespace = "MyApp.Protos";
若需跨程序集使用（如 ClassLibraryA 定义 proto，ConsoleAppB 使用），在 .proto 中加 option csharp_visibility = "public";，否则生成类默认为 internal
确认项目引用了 Google.Protobuf（v3.21.9+ 推荐），且版本与 protoc 工具兼容（新版 protoc 要求 v3.21+ 运行时）

Protobuf 生成类不提供传统意义上的 null 判断，字段访问必须走协议约定的 API：

oneof 字段不能用 if (msg.MyField != null) —— 必须用 msg.MyFieldCase == DeviceReport.MyFieldOneofCase.SensorList 或 msg.SensorList.Count > 0 判断是否设置
repeated 字段（如 sensor_list）返回的是 RepeatedField<sensordata></sensordata>，它永远不为 null，判空只能用 .Count == 0
optional 字段（proto3 中所有字段默认 optional）要判断是否显式赋值，得查 HasStatus 属性（自动生成），而不是 msg.Status == DeviceStatus.OFFLINE —— 因为默认值可能就是 OFFLINE
嵌套消息字段（如 msg.SensorList[0].Value）可能抛 IndexOutOfRangeException，务必先检查 Count

ParseFrom(Stream) 默认读到流结束才停，但真实网络流不会自动关闭。错误常发生在：

TCP 粘包场景下，把整条连接当单个消息读 —— 必须配合长度前缀或分隔符协议
用 MemoryStream 构造后未重置 Position = 0，导致读不到数据
发送端用了 WriteDelimitedTo(stream)，但接收端没用 ParseDelimitedFrom(stream) —— 后者会自动读长度前缀并限制读取范围
异步读取时，Stream.ReadAsync 返回 0 表示连接关闭，但 ParseDelimitedFrom 仍会继续等 —— 应在外层加超时或用 CodedInputStream 手动控制