Go encoding/binary.Uvarint 返回 n=0 时怎样判断数据不完整

调用 binary.Uvarint 后得到 n == 0，通常表示当前传入的字节切片还不够，而不是已经确认数据非法。真正需要先看的，是返回值 n 的正负：n > 0 是成功读取的字节数，n == 0 是缓冲区太小，n 才是无符号整数溢出，并且 -n 表示已经检查过的字节数。

官方文档：https://pkg.go.dev/encoding/binary#Uvarint

排查 n=0 的核心是“补读后再判断”，不要把一次不完整的切片当成格式错误。对于来自网络或文件流的输入，还要设置最大长度，防止异常数据让补读循环一直等待。

先用 n 的符号判断 Uvarint 处在哪个状态

Uvarint 返回的是 (uint64, int)。第二个返回值不是普通的“消费长度”这么简单，而是把成功、数据不完整和溢出编码在同一个整数里。

因此，只有当输入已经达到协议允许的最大 varint 长度，仍然得到 n == 0 时，才应该把它升级为“格式不完整或协议异常”。对 uint64 而言，标准库给出的最大编码长度是 10 个字节；实际协议仍可以设置更小的业务上限。

n=0 时为什么要保留原缓冲区

变长整数通常用最高位表示“后面还有字节”。例如第一个字节的最高位为 1 时，仅凭这一字节无法知道完整数值，调用者必须把下一段输入接到原缓冲区后再试一次。如果直接丢掉旧切片，下一次解码就会从中间字节开始，结果可能变成另一个合法但错误的数字。

package main

import (
	"encoding/binary"
	"fmt"
)

func inspect(buf []byte) {
	value, n := binary.Uvarint(buf)
	// n 的正负同时表达了成功、输入不完整和溢出。
	switch {
	case n > 0:
		fmt.Printf("value=%d consumed=%d\\n", value, n)
	case n == 0:
		// 不能在这里丢弃 buf；它还可能是完整值的前缀。
		fmt.Println("need more bytes")
	default:
		// -n 是已检查的字节数，负值代表 uint64 溢出。
		fmt.Printf("overflow after %d bytes\\n", -n)
	}
}

代码里不要只判断 value == 0。合法的 Uvarint 本来就可以解码出 0，判断成功与否必须看 n。

流式输入怎样补读而不陷入死循环

如果数据来自 socket、管道或分块文件读取，可以先把收到的字节放进缓冲区，再调用 Uvarint。每次 n == 0 都要确认“确实读到了新字节”；如果读取返回 EOF，就应把它作为截断输入处理，而不是无休止地重试。

package main

import (
	"encoding/binary"
	"fmt"
	"io"
)

func decodePrefix(r io.ByteReader, limit int) (uint64, error) {
	// ReadUvarint 直接从 ByteReader 消费字节，适合流式输入。
	value, err := binary.ReadUvarint(r)
	if err != nil {
		// EOF 表示一个字节都没读到，UnexpectedEOF 表示读到半截。
		return 0, fmt.Errorf("read uvarint: %w", err)
	}
	if limit 

当输入对象实现了 io.ByteReader，ReadUvarint 会把“没有读到字节”和“读到一半遇到 EOF”区分为 io.EOF 与 io.ErrUnexpectedEOF。如果你已经拥有完整或部分 []byte，则继续用 Uvarint 更容易控制缓冲区和最大长度；不要为了使用某个 API 而重复复制数据。

排障时重点检查这四个边界

1. 是否把 n==0 当成了永久错误。网络分片下它只说明本次切片不够，应该补读。
2. 是否忘记限制长度。对 uint64 可以用 binary.MaxVarintLen64 做硬上限，再叠加协议自己的更小限制。
3. 是否忽略 n溢出不是“再读一点就好”，应拒绝字段，避免把异常输入继续传给后续逻辑。
4. 是否错误推进了切片。只有 n>0 时才能使用 buf[n:]；n 为 0 或负数时不能按成功路径消费。

一个实用判断顺序是：先判 n > 0，再判 n == 0 是否仍未超过最大允许长度，最后把剩余情况作为溢出或格式错误。这样既不会误拒绝合法的分片数据，也不会让恶意的超长前缀拖住读取。

常见问题

Uvarint 的 n==0 是不是返回了数字 0？

不是。返回的第一个值在出错时为 0，但 n==0 表示 buf 太小。合法数字 0 的成功结果应该满足 n>0。

什么时候该改用 ReadUvarint？

当输入天然是实现了 io.ByteReader 的流，并且你希望标准库区分 EOF 与 UnexpectedEOF 时，可以优先用它；已有字节切片或需要精确控制补读缓存时，继续用 Uvarint。

n

不能按“数据还没到齐”的路径处理。n

记住一句话：n==0 是“当前输入还不足”，n 才是“数值越界”。围绕这两个边界设计补读、上限和错误返回，Uvarint 的排障就不会把分片问题误判成格式错误。