把一笔 128 元账单平均分给三个人，看起来不值得专门做一个应用。但只要把“128 ÷ 3”的结果直接当成三个人的付款金额，界面就很容易出现 42.666666…；即便显示层把每人格式化为 42.67，三份相加也会变成 128.01。真实需求是每人只看到两位小数、所有份额加起来必须严格等于原始账单。这与普通表单的“输入是否为空”是两类不同的问题，关键在于金额的表示与尾差的分配规则。

这里制作一个独立的 HarmonyOS ArkUI 小工具，界面名叫“均分账单”，项目叫 MoneySplit。它输入金额和人数，计算分配明细，遇到非法金额明确提示，不调用后端服务，也不接触银行卡或支付权限。示例将所有金额在运算入口处转为整数“分”，计算完才把分转回两位小数文字。它适合餐费、活动预算或固定费用的简单均分；不涉及税务、汇率和会计凭证处理。

一、先把“等分”从显示问题还原为数据约束

金额经常被当成 number 直接相除、四舍五入、再交给 toFixed(2)。对于展示，这似乎足够；对于守恒校验，却没有定义谁承担最后一分钱。使用二进制浮点数还可能把本应精确的十进制金额带入精度边界。工程中正确的问题不该是“怎么显示成两位”，而是“怎么确保分配总额等于账单总额，且每个人收到的都是整数分”。

例如 128.00 元转成 12800 分，人数为 3。整数除法商是 4266，余数是 2。于是前两个人拿 4267 分，第三个人拿 4266 分，分别显示 ¥42.67、¥42.67、¥42.66。三人合计严格是 12800 分，没有哪一分钱凭空消失。把多出的分按参与者次序分配，是这个示例工具明确采用的规则；实际产品也可以按轮值或事先商定的优先级分配，但必须公开规则，不能让默认排序悄悄改变。

输入约束同样重要。既然金额以元为单位录入，我们允许 0、12、12.3、12.34 等形式；不允许三位小数、负数、科学记数法、带货币符号或首位不合理的数字字符串。金额上限采用最多八位整数元，防止不断放大数据范围。人数是 1～99 的正整数。输入不符合规则时不计算、不更新已有结果，避免让旧明细看起来像新输入的结果。

二、计算层只做纯函数，UI 不参加分钱

在 entry/src/main/ets/common/MoneyMath.ets 中放三个函数，分别负责解析、分钱和显示。拆成纯函数不是形式主义：这样可以直接给它们喂边界样例，不必启动预览器、点击文本框才能发现计算漏洞。为了限制输入为两位小数，解析入口采用严格正则表达式，而不是依赖 parseFloat 宽松地吃掉后面的非法字符。

export function parseCents(raw: string): number | undefined {
  const value = raw.trim();
  if (!/^(0|[1-9]\d{0,7})(\.\d{1,2})?$/.test(value)) {
    return undefined;
  }
  const parts = value.split('.');
  const yuan = Number(parts[0]);
  const fraction = parts.length === 2 ? parts[1].padEnd(2, '0') : '00';
  return yuan * 100 + Number(fraction);
}

export function allocate(cents: number, people: number): number[] {
  const base = Math.floor(cents / people);
  const extra = cents % people;
  const result: number[] = [];
  for (let i = 0; i < people; i++) {
    result.push(base + (i < extra ? 1 : 0));
  }
  return result;
}

export function formatCents(cents: number): string {
  const yuan = Math.floor(cents / 100);
  const fraction = (cents % 100).toString().padStart(2, '0');
  return `¥${yuan}.${fraction}`;
}

allocate 预期只接收经过输入验证、非负且在限制范围内的整数分和合法人数。若准备将该方法开放给多个业务模块，应该再把 Number.isSafeInteger(cents)、people >= 1 作为函数自己的防御性检查，而不是靠调用方约定。这里的上限约束保证计算不会接近 JS 的安全整数边界，但限制范围不是金额算法天生的性质，未来扩大业务额时要重新评估。

当金额是 0 时，系统生成若干个 ¥0.00；当 1 分分给 3 人时，第一人 ¥0.01，另外两人 ¥0.00。若业务要求“每人至少一分钱”，那是另一个约束，需要阻止人数大于总分数，而不能在当前代码里偷偷让总额膨胀。金额小数位为一位时，12.3 按补零解析为 1230 分；没有小数位的 12 按 1200 分处理。整个过程中不对 128/3 做浮点金额除法。

三、在 ArkUI 把计算状态和表单状态拆开

entry/src/main/ets/pages/Index.ets 只负责输入、错误提示与明细。页面初始展示金额 128.00、人数 3 和分摊结果，利于开发者观察“余数 2 分如何被分配”。点击“计算分摊”后才刷新结果；输入时即刻改动数字不会自动改写原有份额，但界面应明确提示“待重新计算”，免得用户以为结果正在随输入实时更新。

import { parseCents, allocate, formatCents } from '../common/MoneyMath';

@Entry
@Component
struct Index {
  @State private amountText: string = '128.00';
  @State private peopleText: string = '3';
  @State private shares: number[] = [4267, 4267, 4266];
  @State private errorText: string = '';
  @State private dirty: boolean = false;

  private calculate(): void {
    const cents = parseCents(this.amountText);
    const people = Number(this.peopleText);
    if (cents === undefined || !/^[1-9]\d*$/.test(this.peopleText)
      || !Number.isInteger(people) || people > 99) {
      this.errorText = '金额最多两位小数，人数为1至99的整数';
      return;
    }
    this.shares = allocate(cents, people);
    this.errorText = '';
    this.dirty = false;
  }

  build() {
    Column({ space: 20 }) {
      Text('均分账单').fontSize(30).fontWeight(FontWeight.Bold)
      Text('以整数分计算，确保分配合计等于账单')
        .fontSize(15).fontColor('#64748B')
      Text('账单金额（元）').fontSize(17)
      TextInput({ text: this.amountText, placeholder: '例如 128.00' })
        .onChange((text: string) => { this.amountText = text; this.dirty = true; })
      Text('参与人数').fontSize(17)
      TextInput({ text: this.peopleText, placeholder: '例如 3' })
        .onChange((text: string) => { this.peopleText = text; this.dirty = true; })
      Button('计算分摊').width('100%').onClick(() => this.calculate())
      if (this.errorText.length > 0) {
        Text(this.errorText).fontColor('#B42318')
      }
      if (this.dirty) { Text('输入已变化，请重新计算').fontColor('#B7791F') }
      Text('分摊明细').fontSize(21).fontWeight(FontWeight.Medium)
      ForEach(this.shares, (cent: number, i: number) => {
        Row() {
          Text(`${i + 1}号参与者`)
          Blank()
          Text(formatCents(cent)).fontWeight(FontWeight.Medium)
        }.width('100%').padding(14).backgroundColor('#F3F6FB').borderRadius(12)
      }, (_cent: number, i: number) => `${i}`)
    }.padding(24).width('100%')
  }
}

这里采用显式的 onChange 同步文本值，符合 TextInput 的状态绑定建议。对真实设备而言还要考虑软键盘遮挡、输入法组合输入与无障碍字号：错误消息应保持足够的对比度，按钮不能靠“颜色红了”作为唯一反馈。若要用系统的输入类型限制键盘，需要再对照目标 SDK 的 InputType 行为验证，不能认为数字键盘就替代了输入验证。

四、用边界矩阵检查的不只是小数位

先测主例：金额 128.00，人数 3，结果应为 42.67/42.67/42.66，合计 128.00。再测 0.01 分给 3 人，预期 0.01/0.00/0.00；12.3 分给 2 人，预期每人 6.15；10.00 分给 4 人，预期每人 2.50。这四组能同时检查整数金额、补零、奇数余数和零值分配。

错误输入要分别覆盖 12.345、-1、1e2、12元、空字符串，以及人数 0、100、2.5。点击按钮后应显示错误并保持上一份明细；修正输入后再次计算，错误消失，结果才更新。这个设计仍有一个界面取舍：当输入已经改变但用户尚未点击计算，旧结果依旧留在下方，所以必须显示“输入已变化，请重新计算”；若产品不允许出现旧结果，可以在 onChange 中清空 shares，但这样也会增加交互干扰。

另外，不要单纯把几个分摊金额字符串拼起来再用浮点数验和。测试里应核对 shares.reduce((a,b)=>a+b,0) === parseCents(amount)，让守恒断言发生在整数分层。人数越多，差异仅表现为部分参与者比其他人多 1 分，任意两人金额差不超过 1 分。假如业务要指定每位参与者的小费、打折或费用上限，则需要另一个算法；均分规则不应假装能够覆盖复杂账单。

五、金额正确不等于完整的支付系统

这个小工具把最容易忽略的尾差分配写成了可测试规则，运算层与界面层有清楚的边界。它既没有发起支付，也没有保证多个参与者实际转账成功，更不具备审计或税务功能。想把它用于真实收费业务，还需要成员身份、费用确认、撤回、并发修改与订单状态管理，并通过独立的服务端校验最终金额。

有时产品经理会问：为什么不让三个人都拿到 42.67 元，再把多出的一分钱从总额扣掉？因为这相当于未经说明更改了账单本身。总额是一条不可随意调整的输入约束；尾差应当反映在参与者的分配上，而不是反过来改变总账。还有一种做法是把余数随机给某个人，这也不适合要求结果可复算的场景。当前规则始终按列表顺序分配，用户下次输入相同金额和人数，就应得到相同结果。若要在成员间长期公平轮换，必须把轮换起点单独设计为可持久化的业务字段，并在界面说明。

当代码和业务范围都比较小的时候，最有效的工程处理往往不是引入重量级库，而是先约束输入、使用整数单位、定义余数归属、给边界结果编写测试。界面看似只多了一个“计算分摊”按钮，隐藏在它后面的却是金额守恒这一条值得明确写进需求的规则。

官方参考：TextInput 输入组件、ForEach、ArkUI 状态管理基础。建议在所用 SDK 下对具体 ArkTS 工程执行编译和交互验证，以上场景可作为验收用例。