首先要检查的是：
输入数据是原始数据吗？如果您尝试解析其他格式（json，xml，csv，二进制格式化程序）或仅是损坏的数据（例如，“内部服务器错误”
html占位符文本页面），那么 它将不起作用 。
什么是线型？
它是一个3位标记，告诉它（广义而言；毕竟只有3位）下一个数据的外观。
协议缓冲区中的每个字段都以标头作为前缀，该标头告诉它表示哪个字段（数字）以及接下来要传输的数据类型。这种“什么类型的数据”对于支持流中 意外
数据的情况至关重要 （例如，您已经在数据类型的一端添加了字段），因为它使序列化程序知道如何读取该数据。数据（或根据需要将其存储为往返）。
有哪些不同的线型值及其说明？
- 0：变长整数（最多64位）-用MSB编码的base-128指示连续性（用作整数类型（包括枚举）的默认值）
- 1：64位-8字节数据（用于
double
，或 可选地 用于long
/ulong
） - 2：长度前缀-首先使用变长编码读取整数；这告诉您要跟随多少字节的数据（用于字符串
byte[]
，“打包”数组，以及作为子对象属性/列表的默认值） - 3：“开始组”-一种使用开始/结束标签对子对象进行编码的替代机制-在很大程度上已被Google弃用，跳过整个子对象字段的成本更高，因为您不能只是“寻找”一个意外的对象宾语
- 4：“结束组”-与3结对
- 5：32位-4个字节的数据（用于
float
，或 可选地 用于int
/uint
和其他小整数类型）
我怀疑是字段引起问题，如何调试呢？
您要序列化到文件吗？在 最有可能的 原因（在我的经验）是已覆盖现有文件，但还没有被截断它; 即 是
200字节；您已经重写了它，但是只有182个字节。现在，流的末尾有18个字节的垃圾将其绊倒。重写协议缓冲区时，文件必须被截断。您可以使用
FileMode：
using(var file = new FileStream(path, FileMode.Truncate)) { // write}或者
SetLength在 写入数据后：
file.SetLength(file.Position);
其他可能原因
您正在（意外地）将流反序列化为与序列化的类型不同的类型。值得仔细检查对话双方，以确保不会发生这种情况。
