Golang二进制协议中变长编码Varint解析-Golang-PHP中文网

应使用 binary.Uvarint 解析无符号变长整数（如长度、ID），因其直接按 LEB128 规则解码；binary.Varint 专为 Protobuf 的 ZigZag 编码设计，会将 byte(18) 解为 9，导致无符号场景结果减半。

binary.Varint 和 binary.Uvarint 到底该用哪个？

binary.Varint

不是“通用变长整数解码器”，它专为 Protocol Buffers 的 ZigZag 编码设计；而 binary.Uvarint 才是标准 LEB128 无符号变长编码的实现。你传入一个原始 byte(18)，期望得到 18，结果却拿到 9——这不是 bug，是 Varint 在执行 ZigZag 反变换：18 >> 1 = 9，且因最低位为 0 不触发取反。

如果协议文档写的是 “varint-encoded uint32” 或你手动生成字节时用的是 binary.PutUvarint，必须用 Uvarint
如果协议明确基于 Protobuf（比如 gRPC 流、.proto 定义字段为 sint32），才考虑 Varint
Varint 返回 int64，Uvarint 返回 uint64，类型不匹配可能引发静默截断（如高位被丢）

单字节解析结果减半？检查是否误用了 Varint

binary.Varint([]byte{0x12})

返回 9，是因为它把 0x12（十进制 18）当作 ZigZag 编码后的值，还原为有符号整数： (18 >> 1) ^ -(18 & 1) = 9 ^ 0 = 9。

这在 protobuf 中完全合理（例如编码 -5 → 9），但对普通协议中的长度字段、id 字段就是灾难。

✅ 正确做法：所有协议中「非负、无符号」的变长字段（如消息长度、数组大小、tag ID）一律用 Uvarint
❌ 常见错误：看到文档写 “varint”，就默认用 Varint，没注意协议实际用的是无符号语义
⚠️ 单字节不是特例：[]byte{0x80, 0x01}（即 0x0180 = 384）用 Uvarint 解得 384，用 Varint 解得 -192（ZigZag 映射后）

解析失败或返回 0？先看输入字节是否合法 LEB128

binary.Uvarint

和 binary.Varint 都要求输入严格符合 LEB128 格式：每个字节低 7 位是 payload，最高位（bit 7）是 continuation flag（1 表示还有下字节，0 表示结束）。非法格式会导致返回 0 且 n == 0。

常见非法输入：字节末尾多出零（如 []byte{0x01, 0x00}）、continuation flag 错位（如 []byte{0x81, 0x01} 中第一个字节 flag=1，但第二个字节 flag=0，本应结束却少字节）
Uvarint 对超长输入敏感：LEB128 最多 10 字节，若传入 11 字节且前 10 字节全 flag=1，函数会返回 0 且 n == 0（表示解码失败）
务必校验返回的 n：
if n

为什么 binary.Varint 不接受 io.Reader？

binary.Varint

签名是 func (buf []byte) (int64, int)，它只从 buf[0] 开始解析第一个 varint，然后立刻停止，**不消费剩余字节，也不支持流式读取**。这和 binary.Read 的行为完全不同。

不能把它塞进 bytes.Buffer 或 bufio.Reader 后调用 —— 没有对应接口
若需从流中连续读多个 varint（如 Protobuf repeated 字段），必须手动切片：v1, n1 := binary.Uvarint(data); v2, n2 := binary.Uvarint(data[n1:])
切片前务必确保 len(data) >= n1，否则 panic；建议用 data = data[n1:] 更新切片再递进，而非硬索引

复杂点在于：varint 解码本身不带边界，你得自己维护字节游标；而协议里 varint 往往嵌套在 tag-length-value 结构中，错一位，后续全崩。最易被忽略的是——你查了半天数值不对，最后发现是 length 字段自己也用 varint 编码，但你用 Varint 去解它，而它其实是无符号的。