Go math/big 怎样安全解析高精度整数

订单号、账户余额的最小单位、外部系统的流水号，都可能超过 int64 能表达的范围。Go 里不要先转成 float64 再转整数，那样可能在中间步骤丢失低位；也不要让解析失败的值继续流入业务。更稳妥的做法是把输入保留为字符串，用 math/big 的 big.Int.SetString 一次完成完整解析，并显式检查成功标记。

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

固定接收十进制文本时使用 SetString(input, 10)；只有确实需要识别 0x、0o、0b 等前缀时才使用 base=0。解析返回 ok=false 就立即返回错误，不能读取失败后的接收值。

• 输入边界先明确：是否允许首尾空白、正负号、前缀和下划线。
• SetString 的第二个返回值是完整解析是否成功，不是“解析了多少位”。
• 高精度阶段始终保留 *big.Int，需要兼容旧接口时才先用 IsInt64 检查范围。

先把输入契约写清楚

标题里的“安全”不只代表能解析大数字，还包括不会把非法输入误当成 0、不会因无限长度输入消耗过多资源，以及不会把进制规则藏在调用方。面向接口的十进制字段，建议先去除业务允许的首尾空白，再固定传入 10；如果字段必须严格匹配原始文本，则删掉 strings.TrimSpace，让空白直接失败。

这里还要区分 big.Int 与 big.Float：前者表示任意精度整数，适合金额最小单位、计数和大 ID；后者是浮点数，存在精度与舍入问题，不是整数解析的替代品。

用 SetString 完整解析十进制

SetString 会把字符串解释为指定进制，并返回接收者和一个布尔值。官方文档明确说明，只有整个字符串都合法时才算成功；失败时接收值未定义，因此代码只保留成功分支里的结果。

package main

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

// parseDecimal 只接受十进制整数，并把允许的外层空白视为输入清洗步骤。
func parseDecimal(raw string) (*big.Int, error) {
	input := strings.TrimSpace(raw)
	if input == "" {
		return nil, errors.New("整数不能为空")
	}

	// base=10 固定协议为十进制，避免 08、0x 等文本被按另一种规则解释。
	value, ok := new(big.Int).SetString(input, 10)
	if !ok {
		return nil, fmt.Errorf("无效的十进制整数: %q", raw)
	}
	return value, nil
}

func main() {
	value, err := parseDecimal("  922337203685477580812345  ")
	if err != nil {
		fmt.Println("parse failed:", err)
		return
	}
	// String 只负责输出，不把高精度值降级为 float64 或 int64。
	fmt.Println(value.String())
}

这个示例的关键不是“能打印出来”，而是错误路径明确：空字符串和包含字母的文本都会返回错误；成功后值一直是 *big.Int。如果接口层不允许空白，可以在调用 SetString 前不做 TrimSpace，把协议约束交给解析器。

需要前缀时再选择 base=0

配置文件或命令行参数如果同时允许十进制、二进制、八进制和十六进制，可以传入 0 让 math/big 按前缀识别。官方文档还说明，只有 base=0 时下划线才按数字分隔符处理；固定传入 10 时，下划线不是合法数字字符。

// parseIntegerLiteral 允许 Go 风格的进制前缀，但不接受空白包围的隐式格式。
func parseIntegerLiteral(raw string) (*big.Int, error) {
	if raw == "" {
		return nil, errors.New("整数文本不能为空")
	}

	// base=0 让前缀决定进制；失败时直接丢弃 value，避免使用未定义结果。
	value, ok := new(big.Int).SetString(raw, 0)
	if !ok {
		return nil, fmt.Errorf("无效的整数文本: %q", raw)
	}
	return value, nil
}

两种策略不要混用：数据库字段、JSON 字符串和订单接口通常更适合固定十进制；开发者工具或表达式配置才可能需要 base=0。如果业务只允许十进制，却使用了 base=0，输入前缀就可能改变解释方式。

解析后如何控制长度和兼容旧接口

高精度并不等于无限制。来自网络、表单或消息队列的文本，应该在进入 SetString 前设置业务允许的最大长度。这个限制是资源保护，不是把数值转换成机器整数；通过后仍然使用 big.Int 进行计算。

// parseBoundedDecimal 同时限制输入长度和数值解析结果。
func parseBoundedDecimal(raw string, maxDigits int) (*big.Int, error) {
	input := strings.TrimSpace(raw)
	if input == "" {
		return nil, errors.New("整数不能为空")
	}
	if maxDigits  maxDigits {
		return nil, errors.New("整数位数超过限制")
	}

	value, ok := new(big.Int).SetString(input, 10)
	if !ok {
		return nil, fmt.Errorf("无效的十进制整数: %q", raw)
	}
	return value, nil
}

// toInt64 只在业务接口明确要求 int64 且值处于范围内时转换。
func toInt64(value *big.Int) (int64, error) {
	if value == nil || !value.IsInt64() {
		return 0, errors.New("整数超出 int64 范围")
	}
	return value.Int64(), nil
}

IsInt64 是转换前的门槛；直接调用 Int64 会把超出范围的值压到 int64 能表示的结果，调用方就可能在没有错误的情况下得到错误业务值。若下游也能接受字符串或 *big.Int，优先保持高精度，不要为了接口方便过早转换。

常见边界与排查方法

可以把错误分成三层：文本清洗是否符合协议、进制解析是否成功、下游类型是否容得下。每层返回自己的错误，调用方就能知道是输入格式问题还是范围问题，而不是只看到一个模糊的“转换失败”。

小结与常见问题

对于超出 int64 的业务整数，推荐使用 new(big.Int).SetString，固定十进制场景传入 10，允许字面量前缀时传入 0；同时限制输入长度，检查 ok，并在确需兼容 int64 时先调用 IsInt64。这样既不会因为浮点中转丢精度，也不会把非法输入或越界值静默带进业务。

SetString 失败后还能读取接收值吗？

不能。官方文档把失败后的值定义为未定义，代码应根据 ok=false 立即返回，不要读取、缓存或继续计算这个值。

为什么不直接使用 strconv.ParseInt？

strconv.ParseInt 适合有明确位宽边界的整数；本篇场景的数值可能超过 int64，所以先用 big.Int 保留完整结果，再按下游契约决定是否转换。