跨境商城多币种金额设计：从 double 精度丢失到汇率快照，订单金额该怎么存？

跨境商城上线第一个月，财务对账时发现总账和支付通道的流水差了几块钱。金额不大，但没人说得清差在哪一笔。查到最后，问题既不在支付通道也不在分账规则，而在一开始把金额存成了double：一张 0.29 美元的优惠券在计算时变成0.28999999999999998，乘 100 再取整就少了 1 分。这种差额不会被任何异常日志捕获，它会安安静静躺在数据库里，直到某天财务报表对不上。

这篇文章讲的就是这件事：当一笔订单上同时存在买家支付币种、平台结算币种和商户提现币种时，金额到底该用什么类型存、一张订单要落下几组金额、汇率是实时查还是落快照、多商户分账的尾差归谁。适用于做跨境电商、多金业务或多币种结算的团队，代码示例以 Java 为主，附 Go 侧的处理方式，表结构按 MySQL 写。

一、先看清一笔跨境订单上有几个金额

很多团队在系统里只有一个amount字段，理由是"国内业务只收人民币"。等到接入第一个海外站点，就会发现问题不是"多加一个币种字段"能解决的。看一个具体场景：

一个中国卖家在平台上卖商品，标价 100 USD；一位日本买家下单，页面按当前汇率显示 14,884 日元；买家实际用 JPY 支付；平台按 7% 抽佣，剩余货款以人民币结算给卖家；卖家过两周发起提现。

这一条链路里至少有六组金额，而且它们的最小单位小数位并不相同：

只要有一个环节用错币种的小数位，或者兑换顺序放错位置，账就会差。下面的设计都是围绕这六组金额展开的。

二、double 和 float 一定会错，这不是概率问题

double是 IEEE 754 双精度二进制浮点，它无法精确表示十进制小数。0.1存进去实际是0.1000000000000000055511151231257827。日常展示看不出来，但只要进入"乘法 + 取整"这两个动作，误差就会暴露：

// 反例：优惠券抵扣doubleprice=29.90;doublecoupon=0.29;doublepayable=price-coupon;// 29.610000000000003longfen=(long)(payable*100);// 2961，本该是 2961，看着没问题…doubleprice2=2.99;doublecoupon2=0.1;longfen2=(long)((price2-coupon2)*100);// 288，本该 289，少 1 分

最后一行少的那 1 分，就是(long)直接截断而非四舍五入的结果。金额在系统里会被反复加、减、乘汇率、拆分账，误差是累积的：单笔看不出，一万笔汇总就跑不掉。财务口径上这叫"无法解释的差错"，比一次明显的报错更难处理。

结论只有一句：金额在内存、数据库、接口三个环节都不能用浮点类型。展示层可以格式化成字符串，计算层必须用整数或十进制类型。

随商在做跨境商城项目时，金额这一层的返工几乎都发生在最初选型上：一旦数据库里已经躺着一批不精确的历史金额，后面再改类型，就要连历史订单、对账流水、结算单一起修，成本远高于一开始就选对。

三、只用long存"分"也不对：币种精度是不同的

知道不能用 double 之后，最常见的第二个坑是"统一用 long 存分"。这个方案在人民币和美元上都正确，一碰到日元就出事：

• JPY、KRW、VND、CLP、XAF、XOF 等币种的小数位是0，100 日元就是 100，没有"分"。
• USD、EUR、CNY、GBP、HKD 等是2位。
• KWD、BHD、JOD、OMR、TND、IQD、LYD 是3位（1 第纳尔 = 1000 fils）。
• 特殊单位如 CLF 是4位。

这是 ISO 4217 定义的 minor unit（最小货币单位）概念，支付通道的 API 也全部按这套规则走。国际卡组织的报文里，金额字段 DE4 本身不带小数点，只存整数，由 DE49（交易币种）决定这串数字末几位是小数——同样一串000000001000，配 USD 是 10.00 美元，配 JPY 是 1000 日元，配 KWD 是 1.000 第纳尔。写死× 100的代码，向 JPY 通道提交 5000 日元会变成 500000，多收一百倍，而且不会报错。

所以正确的做法不是"存分"，而是存最小单位整数，同时明确它是哪个币种的最小单位。代码里绝不允许出现裸long amount，必须是(minor, currency)成对出现。

四、汇率：不做快照，账永远对不上

币种精度问题解决后，第二个对账杀手是汇率。

常见做法是下单时查一次汇率算出应付金额，订单表里存下这个数字就完事，汇率本身不落库。这在小规模时能用，一旦涉及结算、退款、对账就崩：

• 结算时要按"下单时的汇率"还是"支付成功时的汇率"折成结算币种？如果没有快照，事后无法复现当时的折算依据。
• 退款时按退款当日汇率重算，买家拿到的钱与支付时不等值，差额变成汇兑损益，落到用户或平台头上，用户会投诉"为什么退少了"。
• 对账时通道给的明细只有通道币种金额，平台要把它和内部订单对应起来，必须能重算出同一个数字，差一分就对不上。

汇率快照的核心不是"存一个数字"，而是订单只引用快照 ID，不重新查表计算。这样做还有一个附带好处：同一批订单共享一条快照记录，汇率表的膨胀速度可控，按天甚至按小时生成一条记录即可。

五、表结构设计

下面是我在实际项目里用得比较稳的一套最小结构，四张表：币种字典、汇率快照、订单、订单金额明细。

-- 1. 币种字典：把 exponent 从代码里搬进数据，避免到处写 magic numberCREATETABLEcurrency(codeCHAR(3)NOTNULLCOMMENT'ISO 4217 三字码，如 USD/JPY/KWD',nameVARCHAR(64)NOTNULL,exponentTINYINTNOTNULLCOMMENT'最小单位小数位：JPY=0, USD=2, KWD=3',symbolVARCHAR(8)NULL,display_scaleTINYINTNOTNULLDEFAULT2COMMENT'页面展示位数，可与 exponent 不同',statusTINYINTNOTNULLDEFAULT1,PRIMARYKEY(code))COMMENT='币种字典';-- 2. 汇率快照：订单只引用 id，不重算CREATETABLEfx_rate_snapshot(idBIGINTNOTNULLAUTO_INCREMENT,base_currencyCHAR(3)NOTNULL,quote_currencyCHAR(3)NOTNULL,rateDECIMAL(24,12)NOTNULLCOMMENT'1 base = rate quote',rate_typeVARCHAR(16)NOTNULLDEFAULT'MID'COMMENT'BUY/SELL/MID',sourceVARCHAR(32)NOTNULLCOMMENT'报价来源，用于事后追溯',effective_fromDATETIME(3)NOTNULL,effective_toDATETIME(3)NOTNULL,created_atDATETIME(3)NOTNULL,PRIMARYKEY(id),KEYidx_pair_time(base_currency,quote_currency,effective_from))COMMENT='汇率快照';-- 3. 订单：同时保留支付币种与结算币种两组金额CREATETABLEtrade_order(idBIGINTNOTNULLAUTO_INCREMENT,order_noVARCHAR(32)NOTNULL,tenant_idBIGINTNOTNULL,user_idBIGINTNOTNULL,-- 支付币种：买家看到、买家实付pay_currencyCHAR(3)NOTNULL,pay_exponentTINYINTNOTNULL,pay_amount_minorBIGINTNOTNULLCOMMENT'最小单位整数',-- 结算币种：平台与商户结算用settle_currencyCHAR(3)NOTNULL,settle_exponentTINYINTNOTNULL,settle_amount_minorBIGINTNULLCOMMENT'支付成功后才确定',-- 汇率快照引用 + 冗余值（展示与对账都要）fx_snapshot_idBIGINTNULL,fx_rateDECIMAL(24,12)NULL,fx_rate_timeDATETIME(3)NULLCOMMENT'锁价时间',statusTINYINTNOTNULL,create_timeDATETIME(3)NOTNULL,PRIMARYKEY(id),UNIQUEKEYuk_order_no(order_no),KEYidx_tenant_create(tenant_id,create_time,id))COMMENT='交易订单';-- 4. 金额明细：一张订单的各个组成项，金额带符号CREATETABLEorder_amount_item(idBIGINTNOTNULLAUTO_INCREMENT,order_noVARCHAR(32)NOTNULL,currencyCHAR(3)NOTNULL,exponentTINYINTNOTNULL,item_typeVARCHAR(24)NOTNULLCOMMENT'GOODS/FREIGHT/TAX/DISCOUNT/PAYABLE/PAID/REFUND',amount_minorBIGINTNOTNULLCOMMENT'优惠、退款为负数',PRIMARYKEY(id),UNIQUEKEYuk_order_type(order_no,item_type,currency))COMMENT='订单金额明细';

几个刻意的设计点：

订单表同时存pay_*和settle_*两组金额。不要试图只存一组再靠币种字段推导，推导过程需要汇率，而汇率是会变的；两组都落库，才能在退款和对账时"复现当时"。settle_amount_minor允许为 NULL，是因为下单时结算金额尚未确定（汇率可能在支付时锁定），把它留空比塞一个临时值更诚实。

exponent跟着金额一起冗余。严格来说它可以由currency表关联得到，但订单金额明细是财务凭证级数据，币种精度一旦被后台改过（比如某币种重新定义小数位），历史订单就会全部错位。冗余一份，历史数据自洽。

金额带符号。优惠券、退款、冲正都不需要另立字段，用负数表达即可，汇总时直接 SUM。

六、Java 侧的 Money 值对象

有了表结构，代码层必须有一个强约束的 Money 类型，否则迟早有人写出order.getAmount() * rate这种代码。

publicfinalclassMoney{privatefinallongminor;// 最小单位整数privatefinalCurrencycurrency;// 含 code 与 exponentprivateMoney(longminor,Currencycurrency){this.minor=minor;this.currency=currency;}publicstaticMoneyofMinor(longminor,Currencyc){returnnewMoney(minor,c);}/** 唯一的字符串入口，页面与接口都走这里，杜绝从 double 构造 */publicstaticMoneyparse(Stringamount,Currencyc){if(amount==null||!amount.matches("-?\\d+(\\.\\d+)?")){thrownewIllegalArgumentException("金额格式非法: "+amount);}BigDecimalv=newBigDecimal(amount);if(v.scale()>c.getExponent()){// JPY 传 100.5 直接拒绝，而不是悄悄四舍五入thrownewIllegalArgumentException("小数位超过币种精度: "+amount+" / "+c.getCode());}returnnewMoney(v.movePointRight(c.getExponent()).longValueExact(),c);}publicMoneyadd(Moneyother){requireSameCurrency(other);returnnewMoney(Math.addExact(this.minor,other.minor),currency);}publicMoneysubtract(Moneyother){requireSameCurrency(other);returnnewMoney(Math.subtractExact(this.minor,other.minor),currency);}/** 按比例计算（抽佣、折扣），最后一步才舍入 */publicMoneymultiply(BigDecimalfactor,RoundingModemode){BigDecimalresult=BigDecimal.valueOf(minor).multiply(factor).setScale(0,mode);returnnewMoney(result.longValueExact(),currency);}/** 落库/展示用 */publicBigDecimaltoMajor(){returnBigDecimal.valueOf(minor,currency.getExponent());}privatevoidrequireSameCurrency(Moneyother){if(!this.currency.equals(other.currency)){thrownewIllegalArgumentException("币种不一致: "+currency.getCode()+" vs "+other.currency.getCode());}}}

add里的同币种校验是关键：不同币种的金额相加必须显式兑换，不能隐式相加。把这条规则写进类型系统，比写一百行注释有用。

外币换算单独一个方法，并且强制传汇率快照，不接收裸 BigDecimal 以外的隐式来源：

publicstaticMoneyconvert(Moneysource,Currencytarget,BigDecimalrate,RoundingModemode){BigDecimaltargetMajor=source.toMajor().multiply(rate).setScale(target.getExponent(),mode);returnMoney.ofMinor(targetMajor.movePointRight(target.getExponent()).longValueExact(),target);}

Go 侧同理。float64只在展示或统计口径里出现，任何参与记账的运算都不允许：

typeMoneystruct{Minorint64CurrencystringExponentint8}func(m Money)Add(o Money)(Money,error){ifm.Currency!=o.Currency||m.Exponent!=o.Exponent{returnMoney{},fmt.Errorf("币种或精度不一致: %s/%d vs %s/%d",m.Currency,m.Exponent,o.Currency,o.Exponent)}returnMoney{Minor:m.Minor+o.Minor,Currency:m.Currency,Exponent:m.Exponent},nil}// 汇率乘法用十进制库，不要用 float64funcConvert(m Money,targetstring,targetExpint8,rate*decimal.Decimal)(Money,error){major:=decimal.NewFromInt(m.Minor).Shift(int32(-m.Exponent))target2:=major.Mul(*rate)minor:=target2.Round(int32(targetExp)).Shift(int32(targetExp))returnMoney{Minor:minor.IntPart(),Currency:target,Exponent:targetExp},nil}

七、关键流程：锁价、支付、分账、结算、退款

金额和汇率落库之后，剩下的是顺序问题。顺序错了，账一样差。

下单：锁价。从fx_rate_snapshot取一条当前有效记录，写入订单的fx_snapshot_id与fx_rate，同时记录fx_rate_time。快照要有有效期，超时下单直接拒绝并提示刷新，而不是"用最新的汇率再算一遍"——后者会让用户在结算页看到的金额和提交后的金额不一致。

支付：以通道回调为准。买家在支付通道实际支付的币种和金额，才是这笔订单的权威金额。回调报文里的金额是通道币种的最小单位整数，与本地订单的pay_amount_minor必须完全相等（注意不是"近似相等"，差 1 就是异常）。这里要按trade_order.order_no做幂等，通道重复推送是常态。

分账与结算：先兑换，后分账。这是最容易写错的一步。

• 先分账后兑换：每个商户各自拿自己那份去兑换，每次兑换都要舍入，累加起来可能与平台侧总额差几分，而且差额分散在多个商户账上，很难查。
• 先兑换后分账：整单兑换成结算币种只产生一次舍入，分账在同一币种内划分，尾差集中且可控。

推荐后者。分账时按整数最小单位分配，最后一个收款方拿"总额减去前面之和"，而不是自己也去乘抽佣比例：

// splitAmounts: 把总金额按比例拆给多个收款方，尾差给最后一方publicstaticList<Money>split(Moneytotal,List<BigDecimal>ratios){List<Money>result=newArrayList<>(ratios.size());longallocated=0;for(inti=0;i<ratios.size()-1;i++){Moneypart=total.multiply(ratios.get(i),RoundingMode.DOWN);// 一律向下取allocated+=part.toMinor();result.add(part);}result.add(Money.ofMinor(total.toMinor()-allocated,total.getCurrency()));returnresult;}

一律向下取整、尾差给最后一方，是为了保证sum(分账金额) == 支付金额这个恒等式永远成立。财务系统里这个恒等式比"每个人都精确按比例"重要得多。

退款：按原支付币种、原汇率。部分退款要按原支付明细逐条冲减，不能按退款时的汇率重算。只有跨币种赔付场景（用结算币种补偿买家）才需要新的汇率快照，并且要单独记录，不能覆盖原订单的汇率字段。

八、接口边界：JSON 里金额怎么传

后端再严谨，前端一进来用 JS 的Number解析就白费。JavaScript 的 Number 是双精度浮点，安全整数上限是 2^53-1，而且它本身就有浮点误差；很多网关和中间件（日志、风控、监控）也会把 JSON 里的数字当 float 处理。

所以对外的金额字段遵循两条：

1. 金额永远用字符串传输，不用 JSON number。
2. 同时给币种和精度，让调用方不需要自己维护币种表。

{"orderNo":"SO202610140001","pay":{"currency":"JPY","exponent":0,"amount":"14884","amountMinor":14884},"settle":{"currency":"CNY","exponent":2,"amount":"661.10","amountMinor":66110},"fxRate":"0.044412000000","fxTime":"2026-10-14T09:12:33.000+08:00"}

amount给人类看，amountMinor给程序用，两者都提供，比只给一个再让调用方猜要省事得多。时间字段带时区偏移，跨境场景里create_time不带时区是最经典的翻车点之一：同一个时间戳在东京和上海解释出来差一小时，跨日对账就会分到不同的交易日。

九、随商的实现取舍与适用范围

我们在随商跨境商城项目的实施过程中，金额这块最后收敛到"整数最小单位 + 币种字典 + 汇率快照"这一条线上，但没有把所有金额都用DECIMAL(20,8)统一存。原因很实际：小数位固定在 SQL 层，意味着所有跨币种运算都要在应用层做，可一旦有人在 SQL 里写了SUM(amount) * rate，这个约束就失效了；而用整数最小单位，SQL 里任何非整数运算都会显得很别扭，反而逼着开发者回到应用层来算，约束是被动生效的。

订单同时保留支付币种与结算币种两组金额、用fx_snapshot_id串起来，这个设计在随商目前的多币种商城产品里是固定的。代价是订单表字段多一些、写入时多一次快照查询，换来的是退款与对账阶段"任何一笔都能被完整复现"。

这套方案的适用范围：币种数量在几十以内、需要多商户分账与结算的跨境电商或多金业务商城；单日订单量在十万级以内时，一张快照表按小时生成记录完全够用。

什么情况下会退化：如果同时支持的币种上百、且组合交叉频繁（比如任意币种互转的支付网关），快照表会快速膨胀，需要按时效分区并引入报价源主备与异常报价熔断；如果业务实际是 B2B 合同锁价——币种固定、汇率一年一定——整套快照机制反而过重，直接在合同/客户价格表里存固定汇率更合适。随商 ModulithShop 走的是前者，多币种订单与结算逻辑放在同一个模块内，边界靠模块而不是靠服务划分，这样金额与汇率的读写始终在同一个事务内，不会出现跨服务各算一套汇率的情况；一旦拆成独立服务，Money 类型和汇率快照就必须下沉成共享基础库或统一汇率服务，否则每个服务各写一遍换算逻辑，账必错。

十、上线前的排查清单

最后给一份可以直接拿去对照的自检项，都是实际踩过或见过的问题：

• 全局搜索double/float/float64，确认没有任何字段、变量、DTO 参与金额计算。
• 全局搜索* 100和/ 100，每一处都要确认所在币种的 exponent 是否为 2。
• 订单表是否存在currency与amount分离存储、且amount的含义随代码位置变化的情况。
• 汇率是否存在订单表里，订单能否在不查汇率表的情况下复现任意一笔的历史折算。
• 分账结果的求和是否严格等于支付金额，尾差是否有确定的归属方。
• 退款是否按原支付币种和原快照汇率冲减，而不是按当天汇率重算。
• 对外接口的金额字段是否为字符串，是否有amountMinor与币种精度。
• 对账任务里，通道金额与内部金额的比较是否按各自币种的最小单位做整数比较，而不是转成 float 后比大小。
• 所有涉及时间的字段是否带时区，对账的"交易日"定义是否唯一。

金额问题有个共同特征：它不会让程序崩溃，只会让账慢慢对不上。所以它必须靠设计来防，靠排查清单来守，不能指望测试用例覆盖。

随商技术团队长期从事企业商城软件产品研发及项目实施，涉及 Java、Golang、B2B、B2B2C、多商户、企业采购、工业品集采及跨境商城等技术场景。

产品交付源码，支持独立二次开发；如需了解产品与技术方案，可在搜索引擎搜索「随商商城」。