多币种账户，为什么不能只显示一个总余额？
从美元、欧元和一个人民币估值出发，理解原币余额、冻结、可用资金、换汇分录与对账。
账户里有 100 美元和 50 欧元，可以说自己有“150”吗？当然可以写出这个数字，但它没有一个共同单位，也不能直接说明能完成哪一笔付款。
多币种产品看起来是在余额旁边多放几个国旗，真正难的是把“持有什么”“能花多少”和“折合多少”讲清楚。下面用假设的预存资金账户讨论产品与账务设计，不包含授信或透支。
三个问题，应该有三个答案
已入账余额回答账户记了多少钱；冻结或占用回答其中多少暂时不能使用；可用余额回答当前能用于新操作的资金。
| 币种 | 已入账余额 | 已占用 | 可用余额 |
|---|---|---|---|
| USD | 100.00 | 30.00 | 70.00 |
| EUR | 50.00 | 0.00 | 50.00 |
在这个简化模型中，可用 = 已入账 − 占用。真实产品若还有待入账资金、准备金、授信或其他限制，应另外定义，不能机械套用一个公式。
使用者付一笔 80 USD 的订单时，看到“美元余额 100”会以为足够，看到“可用 70，另有 30 占用”才知道现在发生了什么。
总资产可以估值，但不能替代原币
继续假设 1 USD = 7.20 CNY、1 EUR = 8.00 CNY。上面的已入账资金合计估值为 1,120 CNY，可用资金合计估值则是 904 CNY。这里忽略换汇费用，汇率也不是实时数据。
这两个数字都能帮助理解规模，但 904 CNY 的估值并不意味着可以直接发起任意币种的同额付款。能否自动换汇、兑换路径、最低金额、费用和限额，还需要看账户的实际能力。
因此我会保留每个原币余额，在汇总旁注明估值币种、汇率时间和计算范围。展示“总资产”时，不要悄悄把冻结资金也说成可用资金。
金额要带着单位进入系统
一个可靠的金额对象至少包含金额和币种。币种不能靠页面当前选项猜测，也不能在查询或回调里丢失。
不能一律按两位小数处理：JPY 通常按零位小数表示，USD 通常为两位，但具体 API 的最小单位与例外仍须核对。汇率、费用计算和展示还可能各有不同精度。
内部用精确十进制或按明确币种规则换算的整数最小单位，避免二进制浮点直接累计资金。每一步在哪个精度舍入、余数怎样归属，都应能复现。
换汇是一组关联动作
假设一次兑换减少 100 USD、增加 92 EUR。它不应该只是把余额字段从一个数字改成另一个数字，也不能直接把 −100 与 +92 相加，宣称分录不平。
需要分别记录美元侧和欧元侧的资金变化，通过换汇订单、报价和相应的清算或桥接科目关联；每个币种按账本模型保持可核查的平衡。手续费使用自己的币种和分录，业务估值与会计本位币处理另行约定。
当一侧已经确认、另一侧结果未知时，先进入对应的处理中或待核对状态。不能为了让页面看着完整，就提前增加另一币种的可用余额。冲正也应保留原记录，通过关联的逆向记录修正。
对账必须回到每一种币
原始交易、授权占用、最终入账、手续费和退款可能是多条记录，时间也可能不同。对账需要先按币种、账户和提供方引用匹配，再解释跨币种关系。
退款关联原交易，部分退款累计检查上限，重复通知只处理一次。外部超时保留未知，之后用查询和报告收敛；页面上一个绿色勾号不能替代账本确认。
如果总估值刚好相同，也不能据此说所有原币都对平了。美元短缺和欧元多记，可能在某个汇率下互相抵消，却依然是两项真实错误。
界面简洁，解释要完整
我希望默认界面只突出几个有用的信息：每币种可用余额、占用、待处理事项，以及带时间的总估值。点击后再展开对应交易、费用和换汇记录。
这背后需要清楚的数据层次：提供方原始结果、内部资金与状态模型、对外接口、页面展示。原币金额、字符串标识和关联引用要沿链路保留，不能为了“统一展示”提前压成一个总数。