Go math/big 怎么计算超出 int64 的订单金额

订单金额一旦超过 int64，不要把问题简单改成“换一个更大的整数类型”。在 Go 里，最稳妥的做法是先把金额转换成分这样的最小货币单位，再交给 math/big.Int 保存和计算；折扣、税率、分摊比例等不能整除的中间结果，则用 math/big.Rat 保留分数。big.Float 只适合明确接受近似误差的展示或统计场景。

先把订单金额转换为最小货币单位

假设接口传入的是“元”字符串，例如 "123456789012345678901234.56"。先拆出整数部分和小数部分，按两位小数拼成“分”；解析时调用 SetString，并检查返回的布尔值。这样数据从入口开始就没有经过会溢出的中间类型。

package main

import (
    "errors" // 用于报告金额格式错误
    "fmt"
    "math/big"
    "strings"
)

// yuanToCents 把最多两位小数的元字符串转换成分。
func yuanToCents(input string) (*big.Int, error) {
    parts := strings.Split(strings.TrimSpace(input), ".")
    if len(parts) > 2 || parts[0] == "" {
        return nil, errors.New("金额格式不正确")
    }
    fraction := ""
    if len(parts) == 2 {
        fraction = parts[1]
        if len(fraction) > 2 {
            return nil, errors.New("金额最多保留两位小数")
        }
    }
    fraction += strings.Repeat("0", 2-len(fraction))
    centsText := parts[0] + fraction

    cents, ok := new(big.Int).SetString(centsText, 10)
    if !ok {
        return nil, errors.New("金额必须是十进制数字")
    }
    return cents, nil
}

func main() {
    cents, err := yuanToCents("123456789012345678901234.56")
    if err != nil {
        panic(err) // 示例直接终止；服务端应返回参数错误
    }
    fmt.Println(cents.String()) // 输出 12345678901234567890123456
}

这里的关键不是“把 int64 换成指针”，而是让原始十进制字符串直接进入 big.Int。生产代码还应根据币种决定小数位；上例固定两位只是人民币等常见场景的简化。

大整数相加和比较要使用独立的结果对象

big.Int 的算术方法会把结果写入接收者。例如 sum.Add(sum, item) 是常见写法，但在循环中要确认每个订单对象不会被意外改写。更容易维护的方式是让输入值只读、结果单独分配，并用 Cmp 比较订单总额和风控上限。

package main

import (
    "fmt"
    "math/big"
)

func main() {
    // 每个字符串都代表分，避免金额先落入 int64。
    rawOrders := []string{"9000000000000000000000000000", "275", "4800"}
    total := new(big.Int)

    for _, raw := range rawOrders {
        item, ok := new(big.Int).SetString(raw, 10)
        if !ok {
            panic("订单金额不是十进制整数") // 实际服务应记录订单号并返回可定位错误
        }
        total.Add(total, item) // 结果写入 total，不改写 item
    }

    limit, _ := new(big.Int).SetString("9000000000000000000000005000", 10)
    fmt.Println("总金额（分）:", total.String())
    fmt.Println("是否超过上限:", total.Cmp(limit) > 0) // Cmp 返回 -1、0、1
}

不要把 big.Int 当成普通值类型随意复制后再并发修改；它内部带有可变表示，方法也会复用接收者。订单聚合如果跨 goroutine，应该按分片分别计算，再在单一汇总点合并，或者由明确的锁保护。

折扣和税率用 Rat，最后一步才处理小数

例如订单金额是 10001 分，折扣为 12.5%，直接用 float64 计算后再转整数，可能在边界处得到无法解释的结果。big.Rat 能把这段中间过程表示成准确的有理数；真正需要落到分时，再由业务决定取整规则。

// discountCents 计算折后金额，示例规则是向下取整到分。
func discountCents(cents *big.Int, discountPercent int64) *big.Int {
    base := new(big.Rat).SetInt(cents)
    rate := new(big.Rat).SetFrac64(100-discountPercent, 100)
    discounted := new(big.Rat).Mul(base, rate)

    // Num/Denom 是精确分子分母；这里明确采用商的向零截断。
    result := new(big.Int).Quo(discounted.Num(), discounted.Denom())
    return result
}

如果规则是“四舍五入”，不能继续沿用这段 Quo 作为默认答案，而应在分子上加半个分母后再除，并单独处理负数。税率和分摊还要记录原始比例，方便对账时解释每一分钱从哪里来。

数据库和 JSON 边界要保留可还原的金额

内部计算准确并不代表出入口安全。数据库可以保存十进制字符串，或在字段设计允许时保存最小单位整数；JSON 则建议把超大金额输出为字符串，避免 JavaScript 等消费端把它读成不精确的 Number。big.Int.String() 和 big.Rat.FloatString 适合生成面向接口的文本，但不要把格式化结果再当成计算输入。

上线前可以按下面的清单检查：金额是否从字符串进入计算；是否全程使用同一种最小单位；比例结果是否在最后一步取整；数据库驱动和前端协议是否会偷偷转换为浮点数；加法、比较、退款和重试是否共用同一套金额语义。

相关问题

big.Int 能直接用 == 比较吗？

不建议。== 比较的是结构状态，金额大小应使用 Cmp；判断是否为零可用 Sign() == 0。

订单金额一定要用 big.Float 吗？

不一定。结算金额优先用以分为单位的 big.Int；只有统计或展示明确接受近似误差时，才考虑设置过精度的 big.Float。

为什么不把所有金额都存成 big.Rat？

Rat 很适合比例和分数中间值，但结算结果最终仍要落到货币最小单位。直接用 big.Int 保存最终金额，字段语义更清楚，也更容易和账务系统对账。

SetString 解析失败时能继续使用返回的 Int 吗？

不能。必须检查布尔返回值；失败时不要使用该对象的值，应把输入当作格式错误处理。