精确到分的成本分摊 (Exact-Cents Cost Allocation)

用朴素的百分比算术把一笔总额——共享补贴、基础设施账单、预算影响数字——分给多个接收方，得到的各份加起来往往不等于原来的总额。精确到分的分摊是解决办法：一种整数/十进制方法，在币种的最小单位（分）中运算，并保证各份加起来恰好等于总额，无论除法多么不整齐。任何需要让拆分后的总额对到分的软件工程师——工资发放、补贴支付、共享服务分摊——都需要这个模式，而不是浮点百分比。

为什么重要

这是企业软件工程中一个有名字的基础模式：Martin Fowler 的《Patterns of Enterprise Application Architecture》（2002）记录了 Money 和 Allocate，正是因为“把 $100 分成三份”是朴素代码总会做错的问题，而且是悄悄做错——错误在有人对账、发现各份比总额少（或多）一分钱时才浮现。在卫生经济学和 NHS 财务工作中，这并非纸上谈兵：预算影响数字要按地点、年份或信托机构拆分；共享的基础设施和许可成本按员工人数或活动比例分摊到各部门。这些拆分每一个都必须恰好对上，因为一位财务总监若收到加起来不等于总额的各份，就会对整个模型失去信任。

计算方法

朴素方法（错误）：
  份额_i = 舍入(总额 × 比例_i / Σ 比例)     —— 每份单独舍入

精确方法（最大余数法 / "largest remainder allocation"）：
  1. 基数_i = 向下取整(以最小单位计的总额 × 比例_i / Σ 比例)   —— 仅整的最小单位（分）
  2. 余数 = 以最小单位计的总额 − Σ 基数_i                      —— 剩余的分，始终 < 接收方人数
  3. 给第 1 步中小数部分最大的 `余数` 个接收方每人多加 1 个最小单位，
     直到余数耗尽

结果：Σ 份额_i == 总额 始终成立，由构造保证

精确方法从不单独舍入某一份——它把整个分摊作为一次运算来舍入，这正是求和不变量得以成立的原因。

算例

把 $100.00 分成三等份（比例 = [1, 1, 1]）。

朴素方法：$100.00 ÷ 3 = $33.333…，每份单独舍入到最接近的分，得到每个接收方 $33.33。合计：$33.33 × 3 = $99.99——丢了一分钱，而且没有哪一行“错”得足以被肉眼发现。

精确方法：三者的 基数 = $33.33（由 向下取整(10,000 / 3) = 3,333 分/接收方，共 9,999 个最小单位）。剩下 1 分（10,000 − 9,999）。这唯一剩下的一分钱归除法中小数部分最大的接收方——具体是哪一个，是平局处理的内部细节，调用方不应依赖。两个接收方得到 $33.33，一个得到 $33.34，三份加起来恰好 $100.00。

每当要把一个预算影响总额按地点、人群或财年拆分，并与已公布的总额对账时，预算影响分析需要的就是这种算术——关于与之配对的问题，即把许多这样的条目相加而不漂移，见币种安全的成本汇总。

与软件工程的关联

这恰恰就是企业软件架构中的“Money 模式”——针对这类特定缺陷的有名字的基础模式，而不是一次性的小技巧。真实的财务对账故障曾因为同样的缺陷进入生产：用 f64 计算的按比例拆分，按接收方舍入，从未与原始总额核对。它与本仓库的总拥有成本模块直接相关，后者目前用普通浮点数跨年份和方案汇总成本——当 TCO 或预算影响总额需要被分摊而不只是相加时，同样的精确性纪律同样适用。

陷阱

• 先算百分比再舍入，而不是用最大余数法：用浮点百分比分摊，再对每个接收方单独舍入，会叠加舍入误差，很少能加回总额，接收方一多尤其如此。
• 忽略币种最小单位的指数：假定所有币种都是 2 位小数——日元是 0 位，有些币种是 3 位；手写的按比例拆分常把 2 写死，遇到其他币种就悄悄出错。精确分摊例程从币种本身读取指数（ISO 4217）。
• 对已分摊的余数重复分摊：对上一次分摊剩下的部分再次运行分摊例程，又没有幂等性检查，可能把同一分钱两次记给同一个接收方。

参考来源

• Fowler M. "Patterns of Enterprise Application Architecture." Addison-Wesley, 2002——Money 与 Allocate 模式。
• ISO 4217——货币与资金代码标准，定义了每种币种最小单位的指数。