binary.ReadVarint 不存在，Go 标准库仅提供只操作 []byte 的 binary.Uvarint 和 binary.Varint，不支持 io.Reader；从流读 uvarint 需手动封装，安全做法是用 io.ReadFull 逐字节读取并校验 MSB，最多 10 字节后返回 io.ErrUnexpectedEOF。
binary.ReadVarint 为什么不能直接用
Go 标准库没有 binary.ReadVarint 这个函数，它根本不存在。你查文档、翻源码、go doc binary 都找不到——这不是遗漏，是设计取舍。标准库只提供了 binary.PutUvarint 和 binary.Uvarint（用于解码），且它们只操作 []byte，不接受 io.Reader。所以“从流里读变长整型”得自己封装。
如何安全地从 io.Reader 解码 uvarint
核心是先读够字节再调用 binary.Uvarint，不能盲目读 10 字节（uvarint 最多 10 字节，但提前 EOF 就 panic）。必须处理部分读取和错误传播。
- 用
io.ReadFull逐字节读入临时缓冲区，每读一个字节就检查是否结束（最高位为 0） - 最多尝试 10 次，超过即返回
io.ErrUnexpectedEOF - 把收集到的字节传给
binary.Uvarint，它会返回解码值和实际消耗字节数（应等于你传入长度） - 别用
bufio.Reader.ReadByte循环——它在底层可能触发多次系统调用，性能差且不易控制错误边界
func ReadUvarint(r io.Reader) (uint64, error) {
var buf [10]byte
var i int
for i = 0; i < 10; i++ {
_, err := io.ReadFull(r, buf[i:i+1])
if err != nil {
return 0, err
}
if buf[i]&0x80 == 0 {
break
}
}
if i >= 10 {
return 0, io.ErrUnexpectedEOF
}
x, n := binary.Uvarint(buf[:i+1])
if n != i+1 {
return 0, io.ErrUnexpectedEOF // Uvarint 拒绝解析，说明字节序列非法
}
return x, nil
}
signed varint（zigzag 编码）怎么处理
Protocol Buffers 的 sint32/sint64 用 zigzag 编码把有符号数映射成无符号 uvarint 再存。Go 没内置解码函数，得手动转换：
- 先调用上面的
ReadUvarint拿到原始 uint64 - 对结果执行
(v >> 1) ^ -(v & 1)即可还原为 int64（Go 的负号对无符号数做补码运算是合法的） - 如果原始类型是 int32，记得检查是否溢出：
if v < math.MinInt32 || v > math.MaxInt32 - 别直接用
int32(v)强转——zigzag 后的值可能远超 int32 范围，但解码逻辑本身不关心位宽，只关心编码规则
性能和边界情况最容易踩的坑
高频场景（如解析大量 protobuf 流）下，每次分配 [10]byte 看似无害，但逃逸到堆上会触发 GC 压力。更严重的是错误处理缺失：
立即学习“go语言免费学习笔记（深入）”；
- 忽略
binary.Uvarint返回的n值：它可能小于输入长度（比如传入[]byte{0x80, 0x01}，它只消费第一个字节就停，因为 0x80 表示继续，但下一个字节没被验证） - 把网络连接的
io.EOF和协议层的 “uvarint 不完整” 混为一谈：前者是正常结束，后者是数据损坏，应区分返回不同错误类型 - 并发读同一个
io.Reader（如net.Conn）时没加锁，导致字节错乱——uvarint 解码不是原子操作，必须保证读取过程独占
真正难的不是写对逻辑，而是让错误信息能准确定位到哪条消息、哪个字段——这需要把偏移量、上下文 reader 状态一起带上，而不是只抛 io.ErrUnexpectedEOF。
