一页结算先明确哪些金额会变一场球的结算经常同时出现订场充值、赠送金额、球费和不同折扣。把它们直接相加再平均会掩盖规则充值赠送影响场地实际成本球费则可以按人数权重处理。模型先计算充值总额再得到场地费的实际折扣比例。没有充值时比例回到 1避免除以零也保证“原价订场”的输入得到直观结果。折扣只影响场地费而不是全部支出const rechargeTotal input.rechargeAmount input.bonusAmount; const courtDiscountRate rechargeTotal 0 ? input.rechargeAmount / rechargeTotal : 1; const actualCourtFee FeeCalcService.round2(input.courtFee * courtDiscountRate);场地费按实际到场人数均分球费用加权人数做分母。女性折扣为 9 折时每位女性在球费分摊中贡献 0.9 个权重男生单价与女性单价由同一基准导出。球费按权重分摊的原因const totalPeople input.maleCount input.femaleCount; const perCourtFee totalPeople 0 ? FeeCalcService.round2(actualCourtFee / totalPeople) : 0;输入与结果分别使用不同键保存。返回页面时可以恢复上次填写的项目同时保留已计算结果这比把计算过程散落在多个输入控件中更容易复算。把输入和结果分别留在轻量存储关注点处理方式可观察结果一页结算先明确哪些金额会变一场球的结算经常同时出现订场充值、赠送金额、球费和不同折扣。状态不依赖页面文案球费按权重分摊的原因场地费按实际到场人数均分球费用加权人数做分母。女性折扣为分支可回读金额保留两位小数的时机可用一组场地费、充值额、赠送额、球费、男女数量和折扣输入验证操作结果可核对可用一组场地费、充值额、赠送额、球费、男女数量和折扣输入验证先查看实际场地费再核对人均场地费与两种球费单价最后比较男女总额是否与规则一致。金额保留两位小数的时机const femaleDiscountRate input.femaleDiscount / 10; const weightedPeople input.maleCount input.femaleCount * femaleDiscountRate; const maleShuttleFee weightedPeople 0 ? FeeCalcService.round2(input.shuttleFee / weightedPeople) : 0;一场球的结算经常同时出现订场充值、赠送金额、球费和不同折扣。把它们直接相加再平均会掩盖规则充值赠送影响场地实际成本球费则可以按人数权重处理。输入与结果分别使用不同键保存。返回页面时可以恢复上次填写的项目同时保留已计算结果这比把计算过程散落在多个输入控件中更容易复算。输入为零时仍能给出稳定结果return { actualCourtFee, perCourtFee, maleShuttleFee, femaleShuttleFee: FeeCalcService.round2(maleShuttleFee * femaleDiscountRate), totalPeople };可用一组场地费、充值额、赠送额、球费、男女数量和折扣输入验证先查看实际场地费再核对人均场地费与两种球费单价最后比较男女总额是否与规则一致。模型先计算充值总额再得到场地费的实际折扣比例。没有充值时比例回到 1避免除以零也保证“原价订场”的输入得到直观结果。关键实现片段import { FeeInput, FeeResult } from ./Models; export class FeeCalcService { static readonly KEY_LAST_INPUT: string fee_last_input; static readonly KEY_LAST_RESULT: string fee_last_result; static defaultInput(): FeeInput { return { courtFee: 0, rechargeAmount: 0, bonusAmount: 0, shuttleFee: 0, maleCount: 0, femaleCount: 0, femaleDiscount: 10 }; } static loadLastInput(): FeeInput { return AppStorage.getFeeInput(FeeCalcService.KEY_LAST_INPUT) ?? FeeCalcService.defaultInput(); } static saveLastInput(input: FeeInput): void { AppStorage.setOrCreateFeeInput(FeeCalcService.KEY_LAST_INPUT, input); } static saveLastResult(result: FeeResult): void { AppStorage.setOrCreateFeeResult(FeeCalcService.KEY_LAST_RESULT, result); } static loadLastResult(): FeeResult | undefined { return AppStorage.getFeeResult(FeeCalcService.KEY_LAST_RESULT); } static calculate(input: FeeInput): FeeResult { const totalPeople input.maleCount input.femaleCount; const rechargeTotal input.rechargeAmount input.bonusAmount; const courtDiscountRate rechargeTotal 0 ? input.rechargeAmount / rechargeTotal : 1; const actualCourtFee FeeCalcService.round2(input.courtFee * courtDiscountRate); const perCourtFee totalPeople 0 ? FeeCalcService.round2(actualCourtFee / totalPeople) : 0; const femaleDiscountRate input.femaleDiscount / 10; const weightedPeople input.maleCount input.femaleCount * femaleDiscountRate; const maleShuttleFee weightedPeople 0 ? FeeCalcService.round2(input.shuttleFee / weightedPeople) : 0; const femaleShuttleFee FeeCalcService.round2(maleShuttleFee * femaleDiscountRate); return { input, actualCourtFee, courtDiscountRate: FeeCalcService.round2(courtDiscountRate * 10), perCourtFee, maleShuttleFee, femaleShuttleFee, maleTotalFee: FeeCalcService.round2(perCourtFee maleShuttleFee), femaleTotalFee: FeeCalcService.round2(perCourtFee femaleShuttleFee), totalPeople }; } static round2(value: number): number { return Math.round(value * 100) / 100; } static formatMoney(value: number): string { return value.toFixed(2); } }折扣只影响场地费而不是全部支出、球费按权重分摊的原因与把输入和结果分别留在轻量存储共同约束了这条处理链输入先被归类计算或异步调用只在定义的入口发生页面随后读取一个明确的结果。把这些判断分散在按钮回调里会让一次重进、一次重复点击或一次失败返回都变成难以定位的差异。金额保留两位小数的时机不是事后补上的提示而是模型在边界条件下仍然要给出的答案。用户只需要看到可继续的操作模块内部则保留足够的状态来解释为什么当前结果是这样。实施取舍场地费按实际到场人数均分球费用加权人数做分母。女性折扣为 9 折时每位女性在球费分摊中贡献 0.9 个权重男生单价与女性单价由同一基准导出。可用一组场地费、充值额、赠送额、球费、男女数量和折扣输入验证先查看实际场地费再核对人均场地费与两种球费单价最后比较男女总额是否与规则一致。一页结算先明确哪些金额会变所对应的数据不应依赖临时文本或视图顺序。将事实保留为字段、记录或令牌能够让同一动作在再次进入页面后得到一致的解释也为后续把能力收敛为轻量组件留下稳定边界。操作验证可用一组场地费、充值额、赠送额、球费、男女数量和折扣输入验证先查看实际场地费再核对人均场地费与两种球费单价最后比较男女总额是否与规则一致。在验证过程中先观察初始状态再执行唯一的主题动作最后回读结果区或系统状态。若输入不满足条件页面应给出可理解的分支若条件恢复用户可以从当前页面再次发起操作而不需要退出并重新建立上下文。更多系统能力可参考 HarmonyOS 开发者文档。规则落到界面之前一页结算先明确哪些金额会变不是展示层的装饰语而是决定输入如何进入状态、状态如何产生结果的约束。一场球的结算经常同时出现订场充值、赠送金额、球费和不同折扣。把它们直接相加再平均会掩盖规则充值赠送影响场地实际成本球费则可以按人数权重处理。球费按权重分摊的原因需要把可复算的数据留在模型里场地费按实际到场人数均分球费用加权人数做分母。女性折扣为 9 折时每位女性在球费分摊中贡献 0.9 个权重男生单价与女性单价由同一基准导出。金额保留两位小数的时机要求页面把正常路径与异常路径放到同一个可观察范围中。可用一组场地费、充值额、赠送额、球费、男女数量和折扣输入验证先查看实际场地费再核对人均场地费与两种球费单价最后比较男女总额是否与规则一致。当用户重复点击、修改输入或离开后再回来时结果应当来自已定义的状态和规则而不是依赖某一次组件渲染的偶然顺序。操作阶段应观察的字段通过条件初始化默认状态与输入不遗留上一轮结果主动作主题相关值变化与规则一致回读结果或提示可继续操作风险防护点处理结果重复动作单一状态入口不生成旁路数据无效输入条件分支返回明确提示页面重进受控恢复状态可解释状态变化应可复盘结果应可解释并且能在下一次操作时继续被用户使用。每一次状态迁移都应保留足够的业务语义用户能看懂当前结果维护者能从输入、规则和结果之间还原处理过程。把边界条件写成明确分支能够避免异常发生时把旧结果误当成新结果也让后续扩展不必回到页面里寻找隐式判断。