专题Hooks 与状态购物车数量已经加一总价却下一次渲染才跟上。页面同时保存 items 和 total再用 Effect 监听 items 更新 total看起来职责分明实际上维护了两份本可直接计算的信息。先理解问题只要一个值能由当前输入确定就先把它视为派生值。多保存一份状态就多出同步时机、遗漏依赖和中间不一致的风险。总价计算很小的时候直接计算比增加缓存和同步 Effect 更清楚。实现路径列出总价真正依赖的输入数量、以最小货币单位表示的单价以及已明确的优惠规则。在渲染过程中运行纯计算函数去掉负责同步 total 的 Effect。只有测量表明计算明显昂贵时才缓存先保持不可变更新让缓存依赖能正确失效。核心示例typeLine{id:string;unitCents:number;quantity:number};exportfunctionsubtotal(lines:readonlyLine[]):number{returnlines.reduce((sum,line){if(!Number.isSafeInteger(line.unitCents)||!Number.isSafeInteger(line.quantity)||line.quantity0){thrownewError(Invalid cart line);}returnsumline.unitCents*line.quantity;},0);}函数不修改购物车也不负责展示货币符号。页面渲染时调用 subtotal(items)数量与小计来自同一份输入快照。示例仅表达普通小规模购物车的小计超大金额仍需安全整数范围校验或专门十进制方案。容易忽略的边界服务端结算金额、优惠审核状态不一定是本地可推导值不能一并删除。尤其是库存、税费与促销最终结果要清楚标出“本地预估”和“服务端确认”避免客户端计算变成交易事实。怎么验证连续增减数量数量与小计在同一次可见更新中保持一致。移除最后一条记录总价回到 0不保留旧值。输入相同购物车两次函数返回相同结果原数组保持不变。减少状态数量是降低复杂度的一种直接方式。每保留一份状态都应能说明它为什么不能从其他状态得到。适用范围与参考示例用于说明设计与排查方法非完整应用也不代表已经过设备实测。 组件片段需接入对应项目文中自定义函数、示意协议和策略数值需按业务补齐。迁移到 OHOS 时应另外核对适配层支持。相关官方文档与接口背景