Go math/big SetString 返回 nil 后对象为什么仍有旧值

如果复用一个 big.Int 调用 SetString，解析失败后看到对象仍打印出上一次的数字，并不代表这次输入被解析成功。SetString 的判断依据是它返回的 *Int 和 bool：失败时返回 nil、false，而接收对象的值是未定义的，不能继续读取。

最小安全写法是先接收返回值，再决定是否进入业务逻辑：

package main

import (
	"fmt"
	"math/big"
)

func main() {
	input := "12x34"

	// 返回的 parsed 只有在 ok 为 true 时才代表完整输入已经解析成功。
	parsed, ok := new(big.Int).SetString(input, 10)
	if !ok {
		// 失败分支不读取 parsed，也不把接收对象当成结果。
		fmt.Println("不是合法的十进制整数")
		return
	}

	// 成功后再格式化，避免把失败时的未定义值带入业务逻辑。
	fmt.Println(parsed.String())
}

先看 SetString 到底返回什么

SetString(s, base) 同时返回 (*big.Int, bool)。成功时返回接收者和 true；失败时返回 nil 和 false。文档还规定，整段字符串必须合法，不能只因为前半段像数字就算成功。

下面三个值要分开理解：

为什么失败后 String 仍可能打印旧值

关键在于“值未定义”不是“自动清零”。big.Int 是可变对象，内部保存符号和用于表示绝对值的数据。解析过程会写入接收对象；失败时，官方契约没有承诺对象最终处于什么状态。实现细节、已经读入的字符以及原来保留的内部数据，都不应该被调用方当作稳定结果。

所以你可能观察到旧值、部分变化后的值或零值。它们都不能证明输入有效。尤其是下面这种写法，错误地把打印结果当成解析结果：

var z big.Int
z.SetInt64(900)

// 这里会返回 nil,false；失败后的 z 不能再作为本次输入的结果。
parsed, ok := z.SetString("90x", 10)
if !ok {
	// 错误示例：z.String() 可能仍像旧值，但这不是可靠结论。
	fmt.Println("解析失败，但 z 是", z.String())
}

// 正确做法是让失败分支直接返回，parsed 也不能解引用。
_ = parsed

这张图只表达 API 契约：红色区域代表“失败后继续读取接收对象”的风险，绿色区域代表先检查返回值再提交状态。

固定 base，避免把输入边界交给猜测

如果业务字段就是十进制，直接传入 10。如果需要根据 Go 数字字面量前缀识别二进制、八进制或十六进制，再使用 0，并明确记录这个选择。

func parseDecimal(s string) (*big.Int, bool) {
	// base=10 表示只接受十进制数字，不把 0x 前缀当成十六进制。
	return new(big.Int).SetString(s, 10)
}

func parseGoLiteral(s string) (*big.Int, bool) {
	// base=0 让输入前缀决定进制，但仍要求整串符合语法。
	return new(big.Int).SetString(s, 0)
}

还要注意：在 base=0 时，前缀会参与进制判断，下划线也有特定位置规则；当 base 不为 0 时，下划线不会被当作分隔符。不要为了“兼容更多输入”盲目把 base 改成 0，而要让输入格式和业务协议一致。

复用对象时把解析和业务状态隔开

对象复用本身没有问题，问题是失败后仍把暂存对象当成业务值。可以让一个临时 big.Int 接收输入，成功后再用 Set 提交到长期状态：

func updateAmount(current *big.Int, scratch *big.Int, input string) error {
	// scratch 只负责尝试解析，失败时不触碰 current。
	parsed, ok := scratch.SetString(input, 10)
	if !ok {
		return fmt.Errorf("金额不是合法十进制整数: %q", input)
	}

	// 只有成功结果才提交；Set 会把值复制到 current。
	current.Set(parsed)
	return nil
}

如果不需要保留旧业务值，也可以每次用 new(big.Int) 解析；代码更直观。只有在确认失败分支绝不读取接收对象时，才值得把复用作为优化点。

用测试锁住 nil,false 分支

func TestParseDecimal(t *testing.T) {
	// 成功输入检查返回对象和数值。
	parsed, ok := new(big.Int).SetString("900", 10)
	if !ok || parsed.String() != "900" {
		t.Fatalf("parse success = (%v, %v)", parsed, ok)
	}

	// 失败输入只检查 ok 和 nil，不检查接收对象的内部状态。
	parsed, ok = new(big.Int).SetString("90x", 10)
	if ok || parsed != nil {
		t.Fatalf("parse failure = (%v, %v), want (nil, false)", parsed, ok)
	}
}

测试的重点不是断言失败后的 z.String() 等于某个固定值，而是断言调用方遵守返回值契约。这样即使标准库实现调整了失败路径的内部写入方式，业务代码也不会依赖未定义状态。

结论

SetString 返回 nil 后对象仍可能显示旧值，是因为失败时接收对象的值没有定义保证；旧值只是当前内存状态的表象，不是本次输入的解析结果。实际使用时固定合适的 base，同时检查返回的 *Int 和 bool，失败立即退出，成功后再写入业务状态。

常见问题

SetString 失败会自动把 big.Int 清零吗？

不能这样假设。文档只规定失败时接收对象的值未定义，因此不能依赖清零、保留旧值或任何中间状态。

只判断返回的 bool 可以吗？

通常可以用 ok 控制成功分支，但更稳妥的习惯是同时遵守失败时返回指针为 nil 的契约，不在失败分支解引用或保存它。

base=0 和 base=10 有什么区别？

base=10 固定十进制；base=0 会根据输入前缀选择进制，并按相应规则处理前缀和下划线。选择哪一个应由业务输入协议决定。

可以复用同一个 big.Int 吗？

可以，但失败后不能读取它来代表失败输入。若业务状态要保留旧值，建议使用 scratch 对象，成功后再调用 current.Set(parsed)。

官方资料：https://pkg.go.dev/math/big@go1.27.3#Int.SetString