首先要检查的是：

输入数据是原始数据吗？如果您尝试解析其他格式（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);

其他可能原因

您正在（意外地）将流反序列化为与序列化的类型不同的类型。值得仔细检查对话双方，以确保不会发生这种情况。