Go math/big.Int.FillBytes 如何导出固定长度整数：补零规则、溢出判断与协议字段校验

做二进制协议适配时，最容易被忽略的不是把 big.Int 转成字节，而是把它准确放进协议规定的固定长度字段。math/big.Int.FillBytes 适合这个场景：它把整数的绝对值按大端序写入调用方提供的缓冲区，前面不足的部分补零；如果数字放不下，则直接 panic。

把 FillBytes 当成“写入固定宽度无符号字段”的工具，并在调用前用位长检查容量；不要把它当成负数的补码编码器。

先把接口边界说清楚

假设协议规定 amount 是 16 字节无符号大端字段。调用方需要的是一个长度永远为 16 的切片，而不是“刚好能容纳数字”的变长结果。Int.Bytes 返回绝对值的大端字节切片，但长度会随数值变化；FillBytes 则把目标长度交给调用方控制。

这两个方法都不表达负数的符号。如果业务字段是金额、计数器或哈希相关整数，入口处应先拒绝负数；如果协议本来要求有符号补码，则应单独实现并测试那套编码规则。

参数设计：先校验，再写入固定字段

下面的函数将一个 *big.Int 写成指定宽度的无符号字段。BitLen 给出绝对值的有效位数，换算成字节后可以在调用 FillBytes 前挡住容量不足，而不是把错误留给 panic。

package wire

import (
    "errors"
    "math/big"
)

var ErrNegative = errors.New("negative integer")
var ErrOverflow = errors.New("integer does not fit")

func EncodeUnsignedFixed(x *big.Int, width int) ([]byte, error) {
    if x == nil || width  width*8 {
        return nil, ErrOverflow
    }
    buf := make([]byte, width)
    return x.FillBytes(buf), nil
}

这里的真实调用链是 EncodeUnsignedFixed 先检查 Sign 和 BitLen，再让 FillBytes 写入 buf。因此错误可以作为普通返回值交给上层，而不是把协议输入问题变成进程级 panic。

为什么要保留前导零

数字 258 的大端表示只有两个有效字节 01 02，放进 4 字节字段后应是 00 00 01 02。前导零不是多余数据，它决定了下一个协议字段从哪里开始。复用一个更大的缓冲区时，FillBytes 还会先清理多出的高位字节，因此不要把旧内容当作“保留区”。

错误模型：容量不足为什么会 panic

官方实现把容量不足视为调用方违反前置条件：目标缓冲区必须能容纳整数的绝对值。比如 17 字节的数写入 16 字节缓冲区，就不能期待它自动截断低位；截断会让协议字段看似成功，实际上已经改变了金额或标识符。

func mustEncode(x *big.Int) []byte {
    buf := make([]byte, 16)
    return x.FillBytes(buf)
}

mustEncode 只有在调用方已经保证 x.BitLen() 时才合理。对来自网络、文件或用户输入的值，使用前面的显式校验函数更稳妥；测试中还应覆盖刚好 128 位、超过 128 位和负数三条路径。

兼容策略：用 SetBytes 做往返检查

编码之后可以用 SetBytes 重新解析，验证协议字段没有意外改变数值。它同样按大端序解释输入，并把结果视为无符号整数。

func roundTrip(x *big.Int, width int) error {
    encoded, err := EncodeUnsignedFixed(x, width)
    if err != nil {
        return err
    }
    decoded := new(big.Int).SetBytes(encoded)
    if decoded.Cmp(x) != 0 {
        return errors.New("round-trip mismatch")
    }
    return nil
}

这项检查特别适合协议升级或跨语言联调：如果对方把字段当成小端序，或者把负数当作补码发送，比较结果会立即暴露问题。它不能替代字段长度校验，长度仍应在进入解码器时固定检查。

几个容易写错的地方

• 用 x.Bytes() 直接当协议字段，导致小数值的字段长度变短。
• 忽略 Sign，误以为负数会得到带符号的二进制结果。
• 把 width*8 写成固定常量，字段宽度变化时校验和编码不一致。
• 用截断代替溢出错误，悄悄损坏高位数据。

落地前的核对清单

确认协议是否规定无符号大端序；把字段宽度作为参数而不是散落的魔法数字；在 FillBytes 之前检查负数和 BitLen；对边界值做 SetBytes 往返测试。这样写出来的编码函数，接口目标、参数约束和失败行为才是同一套规则。

相关问题

FillBytes 会返回新切片吗？

不会。它把结果写入传入的 buf 并返回这个切片，长度由调用方预先决定。

为什么不用 Bytes 再手动补零？

可以手动做，但容易遗漏容量校验或复制方向。固定宽度场景直接使用 FillBytes 更清楚，校验逻辑也能集中在调用前。

负数应该怎么编码？

先查协议定义。如果字段是无符号值就返回错误；只有协议明确规定补码或其他有符号格式时，才实现对应编码，而不是把 FillBytes 的绝对值当成答案。