Go big.Int.FillBytes 目标切片太短时如何避免数值被截断

把 math/big.Int 写入固定宽度的二进制字段时，最容易忽略的不是调用方式，而是目标切片的长度。FillBytes 会把整数的绝对值写入调用方提供的切片：切片足够长就左侧补零，切片太短则只保留低位字节，高位可能被截掉。

安全做法是先用 BitLen 算出最少字节数，再决定是否允许写入。固定宽度场景还要把“数值能否放下”和“字段是否必须补零”分开处理。下面只讨论导出边界，不讨论大整数运算算法。

结论：调用 FillBytes 前先判断 (x.BitLen()+7)/8 。判断不通过就返回错误，不要把过短切片交给导出函数。

先把容量基线算清楚

对非负整数来说，需要的最少字节数是位数向上取整到字节边界：

byteLen = (x.BitLen() + 7) / 8

例如，1 到 8 位需要 1 字节，9 到 16 位需要 2 字节，刚好在 16 位边界的值并不需要第 3 个字节。零值的 BitLen 是 0，因此计算结果也是 0；如果业务字段宽度固定为 4 字节，零值仍然应写入 4 个零字节。

package main

import (
    "fmt"
    "math/big"
)

// minBytes 返回绝对值占用的最少字节数；零值不需要有效数字字节。
func minBytes(x *big.Int) int {
    if x == nil {
        return 0
    }
    // 加 7 后整除 8，等价于把位数向上取整到完整字节。
    return (x.BitLen() + 7) / 8
}

func main() {
    samples := []*big.Int{
        big.NewInt(0),
        big.NewInt(255),
        big.NewInt(256),
        new(big.Int).Lsh(big.NewInt(1), 16),
    }
    for _, n := range samples {
        fmt.Printf("value=%s bits=%d bytes=%d\\n", n, n.BitLen(), minBytes(n))
    }
}

这个计算也是导出前的基线指标。它不需要先调用 Bytes 创建临时切片，因此可以在固定缓冲区已经存在时直接判断容量。

目标切片太短时，低位看起来仍然像是正确结果

截断最危险的地方在于它通常不会把结果变成明显的乱码。假设一个值需要 3 字节，却只给 2 字节，得到的仍然是一段合法的字节序列，只是高 8 位消失了。校验和、ID、金额或协议字段可能因此对应到另一个完全不同的值。

package main

import (
    "fmt"
    "math/big"
)

func main() {
    value := new(big.Int).SetUint64(0x123456)
    short := make([]byte, 2)
    enough := make([]byte, 3)

    // FillBytes 使用目标切片的完整长度；过短时高位字节不会出现在结果里。
    value.FillBytes(short)
    value.FillBytes(enough)

    // short 只剩 0x3456，enough 才保留完整的 0x123456。
    fmt.Printf("short=%x enough=%x\\n", short, enough)
}

这里的对照可以直接作为排障基线：输入值的有效位数是 21 位，最少需要 3 字节；2 字节目标必然不够。不要用“返回切片长度等于目标长度”判断成功，因为长度本来就是调用方传入的。

固定宽度字段应该先检查，再写入

协议字段往往不是“最少字节数”，而是固定宽度。例如 32 位无符号字段可能要求始终写 4 字节。此时正确流程是先判断最少字节数是否超过字段宽度，判断通过后再让 FillBytes 完成左侧补零。

package main

import (
    "errors"
    "fmt"
    "math/big"
)

var errTooLarge = errors.New("big.Int does not fit fixed-width field")

// fillFixed 将整数写入固定宽度字段，拒绝会发生高位截断的输入。
func fillFixed(dst []byte, x *big.Int) error {
    if x == nil {
        return errors.New("nil integer")
    }
    // FillBytes 写入绝对值；负数必须先按协议规则决定是否允许。
    needed := (x.BitLen() + 7) / 8
    if needed > len(dst) {
        return fmt.Errorf("%w: need %d bytes, have %d", errTooLarge, needed, len(dst))
    }
    // 目标足够长时，FillBytes 会在左侧补零，适合固定宽度字段。
    x.FillBytes(dst)
    return nil
}

func main() {
    field := make([]byte, 4)
    value := new(big.Int).SetUint64(0x123456)
    if err := fillFixed(field, value); err != nil {
        panic(err)
    }
    fmt.Printf("field=%x\\n", field) // 结果为 00123456，保留固定宽度。
}

这个版本把“无法放下”变成了调用方可以处理的错误，而不是让错误的二进制字段继续流入网络或文件。若协议要求大端序，FillBytes 的高位在左侧，正好对应常见的网络字节序；若协议另有编码约定，应在这一层明确转换。

用尺寸对照替代模糊的性能判断

这个问题首先是数据正确性问题，其次才是分配优化问题。可以用下面的确定性尺寸表作为代码审查时的基线：

如果热点路径需要复用缓冲区，复用本身不会改变容量规则：每次写入前仍要检查当前整数的 BitLen。上一次写入比这一次更长时，也要确保本次调用完整覆盖目标切片；固定宽度字段通常天然满足这一点，变长切片则应由调用方明确管理有效长度。

负数、零值和边界测试怎么写

FillBytes 写的是整数的绝对值，不会把负数自动编码成二进制补码。若协议字段是无符号定长字段，负数应在进入导出函数前拒绝；若协议支持有符号值，应使用协议规定的补码或符号位编码，而不是直接依赖 FillBytes。

package bigexport

import (
    "errors"
    "math/big"
)

var (
    ErrNegative = errors.New("negative integer is not allowed")
    ErrOverflow = errors.New("integer overflows destination")
)

// EncodeUintFixed 为无符号固定字段提供可断言的错误边界。
func EncodeUintFixed(dst []byte, x *big.Int) error {
    if x == nil {
        return errors.New("nil integer")
    }
    // 无符号字段不能把负数的绝对值悄悄写出去。
    if x.Sign()  len(dst) {
        return ErrOverflow
    }
    x.FillBytes(dst)
    return nil
}

建议至少覆盖四组边界：零值、刚好放下的最高值、比字段宽度多 1 位的值、负数。对 4 字节字段而言，2^32-1 应成功，2^32 应返回溢出错误，-1 应返回负数错误。

排障速查：为什么结果“像成功”

• 只检查返回长度：返回的仍是传入的目标切片，长度相等不代表没有截断。
• 先调用 Bytes 再复制：这能得到正确的最少字节数，但可能多一次分配；固定缓冲区场景优先用 BitLen 做容量判断。
• 把 FillBytes 当作有符号编码：它导出绝对值，负数语义必须由业务层处理。
• 复用切片但忽略固定宽度：清晰区分“字段宽度”和“本次数值最少字节数”，不要让旧数据的长度决定协议格式。

最后，把容量判断封装成一个小函数，并在测试中断言错误类型。这样代码审查时能直接看到溢出策略，性能讨论也有明确基线：不发生高位丢失、固定字段长度稳定、热点路径不需要为了判断容量额外创建临时字节切片。

相关问题

FillBytes 会返回新切片吗？

不会。它使用调用方提供的切片并返回该切片，调用方仍需自己保证容量和生命周期。

零值应该传入空切片吗？

如果字段是变长数字，空切片可以表示零值；如果字段是固定宽度，应该传入完整宽度的切片，让结果保持协议长度。

怎么导出负数的补码？

不要直接把 FillBytes 当作补码编码器。先依据协议规定计算宽度、符号位和补码规则，再使用明确的字节变换。