Go x/text/currency 现金舍入位数为什么可能不同于记账位数

currency.Cash 与 currency.Accounting 面向不同用途，因此同一币种的舍入参数可能不同。而且区别不一定体现在小数位数 scale 上，也可能体现在 increment 上。只比较“保留几位小数”，可能漏掉步长差异；正确做法是读取并保留这两个参数和对应用途。

官方文档：https://pkg.go.dev/golang.org/x/text/currency

同一币种可以有不同使用场景

一个常见疑问是：同一币种代码没有变化，现金展示与记账展示怎么会得到不同设置？这里的 Unit 说明“是哪种货币”，Kind 则说明“按哪种用途选择舍入和展示属性”。两者是独立维度，不应把一个币种固定成唯一小数位配置。

官方接口提供 Standard、Cash 和 Accounting。当前官方实现中 Accounting 使用标准舍入分支，Cash 使用现金分支的数据。这个实现细节说明两种用途可以从不同数据项取得参数，不意味着任意币种的结果都必须不同，也不意味着库负责给企业确定实际记账制度。

同时读取 scale 和 increment

Rounding 返回 scale 和 increment。scale 表示小数位，increment 的计量单位依赖 10 的负 scale 次方。举一个独立的参数解释：若某条规则是 scale=2、increment=5，则对应步长为 0.05；这只是公式示意，不是在声称某个币种当前必然采用这组参数。

下面完整程序查询几个币种的两种用途，只输出参数，不做浮点金额运算。具体返回值由项目使用的模块及其数据决定，本文没有把未执行的示例描述为实测结果。

package main

import (
    "fmt"
    "golang.org/x/text/currency"
)

type Rule struct {
    Use string
    Scale int
    Increment int
}

// Rules 同时查询两种用途，不在这里执行金额计算。
func Rules(code string) ([]Rule, error) {
    unit, err := currency.ParseISO(code)
    if err != nil {
        return nil, fmt.Errorf("解析币种代码: %w", err)
    }
    cashScale, cashStep := currency.Cash.Rounding(unit)
    bookScale, bookStep := currency.Accounting.Rounding(unit)
    return []Rule{
        {Use: "cash", Scale: cashScale, Increment: cashStep},
        {Use: "accounting", Scale: bookScale, Increment: bookStep},
    }, nil
}

func main() {
    // 固定一组代码作为观察对象，不预先硬编码任何返回值。
    for _, code := range []string{"CHF", "JPY", "USD"} {
        rules, err := Rules(code)
        if err != nil {
            fmt.Println(err)
            continue
        }
        for _, rule := range rules {
            fmt.Printf("%s use=%s scale=%d increment=%d\n",
                code, rule.Use, rule.Scale, rule.Increment)
        }
    }
}

不要把 increment 直接当成“分”的数量，它的单位必须结合 scale。也不要未经解释就把任意返回值拿来当除数，参数查询并不是一份完整舍入算法。

保存币种与规则用途而非展示文本

如果应用缓存这些参数，应让缓存身份包含币种代码和用途。只按币种缓存，会让现金规则与记账规则相互覆盖。若后续升级依赖并重新查询，保留所用模块版本也便于解释数据差异。

业务记录应分别表达原始金额、币种代码、用途以及实际采用的计算策略。格式化后的字符串适合给人阅读，不适合反过来恢复精确金额或判断舍入依据。规则参数与展示结果各有自己的对象，不能只保留一段带货币符号的文本。

区分查询参数和实际金额计算

调用 Rounding 是读取属性，没有修改已有金额变量。设置 Formatter.Kind 是选择格式化用途，也不能据此认定后台账目已经按同一规则重算。若业务需要实际金额运算，还必须明确精确数值表示、舍入模式、负数与临界值处理，以及在单项还是总额上应用规则。

这篇文章只解释 Go 接口和数据分工，不给出结算或会计政策。库内数据属于依赖提供的属性信息，不能仅凭返回值就认定它满足某地区当前全部交易要求。实际产品采用什么策略，应依据已确定的业务约定。

官方文档还指出格式化功能仍在开发中。需要稳定行为时，应明确项目使用的依赖版本，而不是把网页某个版本的返回值复制成永远正确的常量。

常见疑问与排查清单

Cash 一定比 Accounting 少保留小数吗？不一定。差异可能在步长，也可能两项都相同，应查看具体币种参数。

Accounting 就是财务系统的全部精度规则吗？不是。它是库提供的一种 Kind，不能替代应用的存储、计算和业务策略。

换语言标签会改变这里的币种吗？示例明确 ParseISO 固定币种，查询直接使用 Unit；不要把语言推断币种的其他接口混入这段比较。

排查时把币种代码、用途、scale、increment 和依赖版本放在同一条诊断记录里，先确认是在比较同一对象，再检查格式化层和实际计算层是否采用了各自正确的策略。

参考：Kind.Rounding 文档、官方 Kind 实现。