Protobuf反序列化失败主因是未用匹配的生成类解析器，须用MyMessage.Parser.ParseFrom而非泛型Deserialize；含长度前缀需ParseDelimitedFrom；字段判空应查HasXXX而非null；oneof需用Case枚举判断。
Protobuf 反序列化失败：找不到类型或抛出 InvalidProtocolBufferException
核心原因不是数据损坏，而是反序列化时用的 messageparser<t></t> 或 parsefrom 方法没匹配到正确的生成类。c# 的 protobuf（google.protobuf）不靠运行时反射自动识别类型，必须显式传入与 .proto 文件编译后完全一致的生成类。
- 确保你用
protoc --csharp_out=.生成了 C# 类，并且项目引用了Google.ProtobufNuGet 包（v3.21+ 推荐） - 反序列化时必须使用对应消息类型的静态解析器，比如
MyMessage.Parser.ParseFrom(data)，而不是泛型Serializer.Deserialize<t></t>那套逻辑 - 如果从网络或文件读取的是带 length-delimited 前缀的多条消息（常见于 gRPC 流或
WriteDelimitedTo），不能直接ParseFrom(byte[])，得用CodedInputStream手动跳过前缀 - 错误示例：
MyMessage.Parser.ParseFrom(buffer)报InvalidProtocolBufferException: Protocol message contained an invalid tag→ 很可能是 buffer 开头多了 4 字节长度前缀，或 buffer 实际是嵌套在另一个消息里
如何正确加载 .proto 编译后的 C# 类（不是手动写类）
Protobuf 在 C# 里不支持“动态加载 .proto 文件并运行时解析”，所有类型必须提前编译。所谓“解析数据”依赖的是编译生成的 partial class 和内置的 Parser 字段。
- 用官方 protoc 工具生成：安装
protoc后执行protoc --csharp_out=. user.proto，会生成User.cs（含User.Parser） - VS 中更稳妥的方式是用
Grpc.Tools+<protobuf include="user.proto"></protobuf>，由 MSBuild 自动触发生成，避免手动生成路径错乱 - 生成类默认是
internal，若需跨程序集访问，加option csharp_namespace = "MyApp.Protos";并在 .proto 顶部声明，同时在生成时用--csharp_opt=global - 别试图把 .proto 内容读成字符串再喂给某个 API——C# 的 Google.Protobuf 没提供 runtime schema 解析能力
从 Stream 读取时卡死或抛 EndOfStreamException
Protobuf 的二进制格式本身不自带长度信息，ParseFrom(Stream) 默认一直读到流结束。但真实场景中，多数传输协议（如 TCP 粘包、HTTP body、Kafka record）都要求明确消息边界。
- 如果发送端用了
message.WriteDelimitedTo(stream)，接收端就必须用MyMessage.Parser.ParseDelimitedFrom(stream)，否则会等不到 EOF 而卡住 -
ParseDelimitedFrom会先读一个 varint 表示长度，再读对应字节数——这个长度是 Protobuf 内部编码的 payload 长度，不含前缀本身 - 不要对同一
Stream多次调用ParseDelimitedFrom却忘了stream.Position已变；尤其别在MemoryStream上反复用，容易读越界 - 调试技巧：用
BitConverter.ToString(buffer).Replace("-", " ")打印前 20 字节，看开头是不是小端 varint（例如0A表示长度 10，0C表示 12）
字段值为 null 而不是默认值？检查 oneof 和 optional 的 C# 行为
C# 生成类中，optional 字段（proto3）和 oneof 成员默认是可空引用类型或 Nullable<t></t>，但它们的“未设置”状态不等于 null 或 default，而是靠内部 has_XXX 标志位控制。
- 不要用
obj.MyStringField == null判断是否设置，应查obj.HasMyStringField（字段名首字母大写 +Has前缀） - 对于
oneof，生成类会有一个Case枚举（如MyUnionOneofCase.Name），用obj.OneofFieldCase == MyUnionOneofCase.Name判断分支 - proto3 中
int32等标量类型没有has_属性（因为无法区分 0 和未设置），如需区分，必须改用wrapper类型（如google.protobuf.Int32Value） - 生成类默认不开启
enable_field_accessors = false，所以字段是自动属性；若手动设了set逻辑，可能绕过has_标志更新，导致序列化丢失该字段
实际用起来最常绊脚的是：以为数据格式通用，结果发现发送端用 WriteDelimitedTo、接收端却用 ParseFrom(byte[])；或者把生成类当成普通 DTO 直接 new + 赋值，却忘了 oneof 必须用指定 setter（如 obj.Name = "x"）才能触发标志位更新。这些细节不报错，但序列化出来就是空或错乱。
