Go big.Int 怎么用 FillBytes 写入固定长度缓冲区

需要把 big.Int 写进固定长度字段时，直接使用 Bytes() 往往不合适，因为它返回的是绝对值的最短大端表示，前导零不会保留。正确做法是先分配目标长度的 []byte，再调用 x.FillBytes(buf)：它会清空整个缓冲区，把绝对值按大端放在右侧，并在左侧自动补零。

但有一个关键边界：如果数值的绝对值放不进缓冲区，FillBytes 会直接 panic。因此，长度来自外部协议或配置时，应在调用前用 BitLen 做容量检查。

官方文档：https://pkg.go.dev/math/big

问题通常出在 Bytes 返回了变长结果

假设协议要求一个整数始终占 16 字节。数值 0x1234 的有效内容只有两个字节，Bytes() 返回 []byte{0x12, 0x34}，长度是 2，而不是 16。若调用方直接发送这两个字节，后续字段的位置就会提前，接收端也无法按固定偏移解析。

package main

import (
	"fmt"
	"math/big"
)

func main() {
	x := new(big.Int).SetInt64(0x1234)
	minimal := x.Bytes()

	// Bytes 返回最短大端表示，不保留固定字段所需的前导零
	fmt.Printf("len=%d bytes=%x\n", len(minimal), minimal)
}

看到长度小于协议宽度时，不需要手工计算从哪个下标开始复制，也不用先调用 Bytes() 再补零；FillBytes 正是为固定长度或预分配切片准备的。

最小写法：分配目标长度后直接填充

package main

import (
	"fmt"
	"math/big"
)

func main() {
	x := new(big.Int).SetInt64(0x1234)
	buf := make([]byte, 16)

	// FillBytes 返回的就是传入的 buf，并按大端在左侧补零
	out := x.FillBytes(buf)
	fmt.Printf("len=%d bytes=%x\n", len(out), out)
}

结果长度固定为 16，最后两个字节是 12 34，前 14 个字节都是 00。这里的“零扩展”发生在高位一侧，也就是大端字节串的左侧。方法返回的切片与传入的 buf 是同一片存储，不会另建一个不同长度的结果。

用 SetBytes 回读，确认字节序没有弄反

FillBytes 和 SetBytes 都采用无符号大端语义。写入后再回读，是定位字节序问题最直接的检查方式。

func roundTrip(x *big.Int, width int) bool {
	buf := make([]byte, width)
	x.FillBytes(buf) // 写入固定宽度的大端绝对值

	decoded := new(big.Int).SetBytes(buf)
	// SetBytes 读取无符号大端整数，因此比较绝对值
	return decoded.Cmp(new(big.Int).Abs(x)) == 0
}

如果回读值不同，优先检查两件事：目标协议是否真的使用大端，以及缓冲区是否包含额外的版本位、符号位或长度头。FillBytes 只负责纯整数的固定宽度绝对值，不会替你编码协议元数据。

定位 panic：缓冲区容不下绝对值

官方源码对这个边界写得很明确：绝对值无法放入 buf 时，FillBytes 会 panic。最少字节数可由 (x.BitLen()+7)/8 得到；零值的 BitLen() 是 0，因此需要 0 个有效字节，但仍能写入任意长度的全零缓冲区。

package fixedint

import (
	"fmt"
	"math/big"
)

func EncodeUnsignedFixed(x *big.Int, width int) ([]byte, error) {
	if x == nil {
		return nil, fmt.Errorf("整数不能为空")
	}
	if width  width {
		return nil, fmt.Errorf("整数需要 %d 字节，目标缓冲区只有 %d 字节", required, width)
	}

	buf := make([]byte, width)
	return x.FillBytes(buf), nil // 容量已检查，不会因过小而 panic
}

把检查封装在协议编码函数里，比在调用处用 recover 接 panic 更清晰。panic 表明调用约束被破坏，而不是正常的输入分支；能在边界处返回错误，就不要依赖异常恢复。

负数不会编码成补码

FillBytes 写的是 绝对值。因此 0x1234 与 -0x1234 得到相同字节内容。它不会生成二进制补码，也不会自动占用一个符号字节。

func sameMagnitudeBytes() bool {
	positive := big.NewInt(0x1234)
	negative := big.NewInt(-0x1234)

	a := positive.FillBytes(make([]byte, 4))
	b := negative.FillBytes(make([]byte, 4))

	// FillBytes 忽略符号，只编码两者相同的绝对值
	return bytes.Equal(a, b)
}

如果协议字段是有符号整数，需要先确认它采用“独立符号位”“符号加绝对值”还是“固定宽度二进制补码”。这些规则必须由协议层显式实现，不能把 FillBytes 的绝对值结果直接当作有符号编码。

复用缓冲区时注意所有权

FillBytes 会先清空整个缓冲区，再写入当前值，所以复用一个固定大小的切片不会残留上一个大数的高位字节。这对循环编码很方便，但返回值仍指向同一底层数组：如果下游需要长期保存本轮结果，应先复制。

func snapshot(x *big.Int, scratch []byte) []byte {
	x.FillBytes(scratch) // 每次都会覆盖整个 scratch

	// 下游要长期持有结果时复制，避免下一次复用改写旧内容
	result := make([]byte, len(scratch))
	copy(result, scratch)
	return result
}

用表驱动测试覆盖容量边界

func TestEncodeUnsignedFixed(t *testing.T) {
	tests := []struct {
		name    string
		value   string
		width   int
		wantHex string
		wantErr bool
	}{
		{name: "零值", value: "0", width: 4, wantHex: "00000000"},
		{name: "刚好容纳", value: "ffff", width: 2, wantHex: "ffff"},
		{name: "左侧补零", value: "1234", width: 4, wantHex: "00001234"},
		{name: "容量不足", value: "10000", width: 2, wantErr: true},
	}

	for _, tt := range tests {
		t.Run(tt.name, func(t *testing.T) {
			x, ok := new(big.Int).SetString(tt.value, 16)
			if !ok {
				t.Fatalf("测试值无效: %s", tt.value)
			}

			got, err := EncodeUnsignedFixed(x, tt.width)
			if (err != nil) != tt.wantErr {
				t.Fatalf("错误状态不符: %v", err)
			}
			if err == nil && hex.EncodeToString(got) != tt.wantHex {
				t.Fatalf("编码结果=%x, want=%s", got, tt.wantHex)
			}
		})
	}
}

上面四组数据分别验证全零覆盖、精确容量、左侧补零和不足时返回错误。若协议允许负数，应另建一组专门测试协议的有符号编码，而不是继续复用无符号断言。

最后检查这六点

• 目标字段是否为固定长度、无符号、大端整数。
• 缓冲区长度是否来自可信协议常量，而不是未经检查的外部输入。
• 调用前是否用 BitLen 计算了最少字节数。
• 是否理解负数只会编码绝对值，不会生成补码。
• 复用缓冲区后，下游是否错误持有同一底层数组。
• 测试是否覆盖零值、刚好容纳、富余空间和容量不足。

相关问题

FillBytes 会保留原缓冲区里的旧内容吗？

不会。当前实现会清空整个缓冲区，再写入数值，因此高位未使用区域会变成零。

为什么不直接用 append 补零？

可以手工实现，但更容易写错补零方向、覆盖范围和容量检查。固定长度场景直接用标准库方法更清楚。

FillBytes 与 Bytes 的核心区别是什么？

Bytes 返回最短长度的新字节切片；FillBytes 写入调用方提供的固定长度或预分配切片，并用前导零填满。

处理固定长度整数时，最可靠的思路是把“数值是否装得下”和“按什么协议编码”分开：先用 BitLen 守住容量边界，再让 FillBytes 完成绝对值的大端零扩展。