Go 大整数解析返回 nil 但不报错怎么办

如果你用 math/big.Int.SetString 解析大整数，拿到 nil 却没有看到 error，先别把它当成标准库漏报错。这个方法的返回值本来就是 (*big.Int, bool)：第二个值才是成功标志，解析失败时返回的整数指针为 nil，接收者的值也不应该继续使用。

官方地址：https://pkg.go.dev/math/big

这类问题最常见的根因是进制参数和输入字符不匹配。例如，字符串 ff 按十进制解析会失败，按十六进制解析才表示 255；如果把 base 设为 0，还要遵守 0x、0b 或八进制前缀规则。排查时把“返回值契约”和“进制规则”分开看，通常很快就能定位。

先读懂 SetString 的两个返回值

SetString 不采用“数值加 error”的形式，而是返回一个可能为空的 *big.Int 和一个布尔值。只有两个返回值同时满足“指针非 nil、布尔值为 true”时，调用方才可以把结果交给后续计算。

package main

import (
	"fmt"
	"math/big"
)

func parseDecimal(text string) (*big.Int, error) {
	// 显式指定十进制，避免调用方误以为输入会自动按前缀识别。
	value, ok := new(big.Int).SetString(text, 10)
	if !ok || value == nil {
		// 失败时不要继续读取 value，也不要把失败当成数字 0。
		return nil, fmt.Errorf("不是合法的十进制大整数: %q", text)
	}
	// 只有成功标志和返回指针都可靠时，才把结果交给调用方。
	return value, nil
}

func main() {
	value, err := parseDecimal("123456789012345678901234567890")
	if err != nil {
		fmt.Println(err)
		return
	}
	// String 只负责展示已确认成功的大整数。
	fmt.Println(value.String())
}

这里的 error 是边界函数自己补出来的业务错误，不是 SetString 原生返回的第三个值。官方文档明确说明：整个字符串必须符合给定进制，失败时返回的数值为 nil，接收者的值未定义。也就是说，不能只检查“返回对象有没有被分配”，更不能忽略第二个返回值。

检查 base 与输入前缀

base 必须是 0，或者 2 到 big.MaxBase 范围内的进制。显式传入 10 时，ff 中的 f 不是十进制数字；显式传入 16 时，它才是合法的十六进制字符。

当 base=0 时，前缀参与选择进制：0b 或 0B 表示二进制，0、0o 或 0O 表示八进制，0x 或 0X 表示十六进制；没有这些前缀时按十进制理解。显式指定非零进制时，不要把“前缀自动识别”混进调用约定里。

另一个容易忽略的边界是下划线。base=0 支持放在前缀与数字之间、或连续数字之间的下划线；显式进制不会把下划线当作分隔符。若配置格式允许用户写 1_000，应明确选择自动进制规则或先做自己的格式清理，但清理也要保留可诊断的原始输入。

让失败路径先返回

不要写成“先把返回值存起来，后面再看看能不能用”。把检查放在解析边界，后续代码就不需要猜测这个大整数是否有效。

package main

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

func parse(text string, base int) (*big.Int, error) {
	// 只去掉输入两端的空白，不改变数字内部的字符。
	raw := strings.TrimSpace(text)
	if raw == "" {
		return nil, fmt.Errorf("大整数文本不能为空")
	}
	// 使用调用方选择的进制，成功布尔值必须与返回指针一起检查。
	value, ok := new(big.Int).SetString(raw, base)
	if !ok || value == nil {
		// 保留原始文本，便于日志或接口错误定位；不要输出敏感业务数据。
		return nil, fmt.Errorf("无法按 base=%d 解析大整数 %q", base, raw)
	}
	return value, nil
}

func addOne(text string, base int) (*big.Int, error) {
	value, err := parse(text, base)
	if err != nil {
		return nil, err
	}
	// 在确认解析成功后再创建结果，避免错误路径参与计算。
	return new(big.Int).Add(value, big.NewInt(1)), nil
}

func main() {
	result, err := addOne("ff", 16)
	if err != nil {
		fmt.Println(err)
		return
	}
	fmt.Println(result.String())
}

这个封装还有两个好处。第一，空白处理、进制选择和错误消息集中在一个入口，调用方不会各写一套规则。第二，错误发生在数据边界，后面的加法、比较或序列化逻辑只接收已经确认成功的 *big.Int。

把“没有报错”与“解析成功”分开

如果代码只写了 value, _ := ...，看起来就像“没有 error，所以应该成功”。但下划线只是丢弃了布尔值，并没有把失败变成成功。更隐蔽的情况是直接使用接收者：

package main

import (
	"fmt"
	"math/big"
)

func main() {
	target := new(big.Int)
	// 这里故意使用十进制，ff 中包含超出十进制的字符。
	parsed, ok := target.SetString("ff", 10)
	if !ok || parsed == nil {
		// 失败后立即结束；不要读取 target，也不要把它当作 0。
		fmt.Println("解析失败")
		return
	}
	fmt.Println(parsed.String())
}

target 是接收者，parsed 是方法返回的指针。失败时官方文档不保证接收者保留什么值，所以“检查 target.Sign() 是否为 0”不是可靠的成功判断。正确的判断对象是返回的 ok 和 parsed。

用表格排查常见输入

可以把排查顺序固定为：先记录原始文本和期望进制，再检查 ok，随后才看返回对象；如果使用 base=0，再检查前缀、下划线和字符位置。这个顺序比先打印接收者的数值更可靠，因为失败后的接收者不具备可依赖的业务含义。

SetString 为什么不返回 error？

它采用“结果指针加成功布尔值”的解析接口，调用者可以通过布尔值判断格式是否有效。若需要统一错误信息，可以像本文的 parse 函数一样在边界层把 false 转换成自己的 error。

base=0 和 base=10 应该怎么选？

输入格式由程序控制且明确是十进制时，显式使用 10 更直观；输入允许 Go 风格前缀时才选择 0，并在接口文档中写清楚前缀和下划线规则。

解析失败时能不能把 nil 当作 0？

除非业务协议明确规定空值等于数字 0，否则不应该这样做。格式错误、缺失值和合法的数字 0 是三个不同状态，静默合并会让上游数据问题延迟到更难排查的位置。

最后记住一句话：SetString 的“没有 error”不等于“解析成功”。先确认 ok，再确认返回指针，最后才让大整数进入计算；而 base 与前缀规则，正是返回 nil 的第一排查点。