旅费账本的三人版已经完成整数分守恒、多人参与式分摊、转账建议和 schemaVersion=2 的持久化恢复。最后一个容易让实际用户困惑的场景却是旅行结束之后：十一月这次旅行已经核对清楚，大家仍想看看当时每笔费用由谁支付、谁承担多少，却不希望某个人误触编辑按钮，导致旧账反复变化。与此同时，下一次周末旅行应该从零开始录入，而不是删除上次的五笔费用，失去追溯依据。 因此本篇选择一个与前五篇不同的工程目

咖啡手记已经具备筛选、收藏、自定义配方、集中提交和稳定列表，真正交付之前却仍有一个必须回答的问题：用户准备换设备，复制了一段配方备份文本，如何确认它不会覆盖内置配方、制造重复 ID，或者把已经不存在的配方重新放进收藏列表？如果只在“导入”按钮里调用 JSON.parse() 再把数组赋给 @State，页面也许能立即出现几张卡片，但下一次启动、删除配方和开启收藏筛选时就可能暴露数据断裂。 这篇作为

确认按钮最容易把一个练习项目变成有风险的业务系统。用户在“银幕影厅”选中了 A1、A2、B1，页面显示三张票合计144元，按下“确认”后，真的可以把这三席记作已购吗？不能。前三篇构建的 CinemaSeats 从来没有接入服务端库存：第一篇实现4排×6列座位、禁售与三席上限；第二篇用绝对截止时间实现五分钟本地暂选；第三篇将 hold_draft_v1 记录在 Preferences，要求启动时完整

一个快递运费计算器看似只有“重量乘单价”，但最容易让产品被投诉的不是界面，而是边界重量附近的一分钱误差。例如首重一公斤8元，续重每不足半公斤也按半公斤计，那么1.00公斤收费8元，1.01公斤却应收费10元。若页面先把 1.01 四舍五入为一位小数，就会错误显示8元。再叠加偏远地区附加费、空白输入、连续小数点和非法负数，原本的两个输入框就变成了一套需要明确定义的数据处理规则。 这里用纯 ArkTS

旅费账本已经会算账：第四篇加入陈以后，李、周、陈三人能够按参与名单均摊、固定分配和比例分配，再根据“已付减应承担”给出转账建议。但一个实际交付问题一直没有解决：这些账目能不能安全地跨启动保存，以及升级后还能不能按原来的规则算出同样结果？ 如果应用退出就丢掉五笔费用，前面精心处理的余分守恒便只存在于一次运行中；如果把整个页面状态随意序列化，明天修改模型字段又可能导致无法解析或悄悄算错。 第五篇继续使

用户把一条新配方“桂花燕麦”加入咖啡手记后，回到首页输入“燕麦”，再切换“冷饮”，页面应该出现什么？如果搜索框在修改原始配方数组、分类栏又在修改同一个数组，用户很可能看到搜索结果突然消失，而且关闭筛选仍恢复不了完整数据。更隐蔽的是：列表使用数组下标作为组件标识，删掉第一张卡片后，下面的收藏按钮可能短暂呈现上一张卡片的状态。第五篇要解决的不是再做一个好看的搜索框，而是让查询条件、业务数据和渲染列表拥

五分钟暂选还剩两分十秒，用户临时切到地图应用，再回到“影厅座位编排”，页面却重新显示了空座位图。另一种情况更难发现：上一轮的倒计时已经结束，重新启动后，界面仍将 A1、A2、B1 涂成“暂选中”。这两个现象表面上都是界面恢复问题，本质却是把临时会话状态与可恢复的业务草稿混为一谈。前两篇已经构造了四排六列的座位模型与基于绝对截止时间的本地暂选机制，这一篇补上应用重新进入时的恢复规则，并明确哪些历史记

把一张手机图鉴页面拖到横向窗口，最显眼的问题往往不是“组件太窄”，而是内容被直接拉伸：照片变得很扁，卡片文字横跨大半个屏幕，收藏按钮离标题越来越远。于是开发者加上“宽度超过某个值就换一套页面”的判断，结果布局变漂亮了，刚刚选中的翠鸟和收藏状态却在切换后消失。对 HarmonyOS 的多窗口、平板和二合一设备来说，排版变化与业务状态变化应当彼此解耦，不必为一列、两列和三列分别维护三份页面数据。 这里

三个人一起旅行，李支付了酒店费，周付了交通费，陈临时加入并和两人一起吃饭。打开旧版“旅费账本”，你会发现问题并不在加一个头像：第三篇的 share=both/li/zhou 只能表达两人的承担关系。若把每笔费用直接平均除以人数，不仅会改变原来两人时期的历史账，还会让“陈没有参加的住宿”错误地算到陈头上。更麻烦的是，金额用整数分保存后，三人分一分钱不可能均分；如果算法悄悄生成小数分，最后的转账建议一

“收藏按钮明明已经点亮，退出重进却没有保存；编辑框刚修改完配方名，列表又出现旧名字。”当配方卡片、筛选栏和编辑表单都堆在 Index.ets 里时，这两种问题通常混在一起。第三篇已经把 CoffeeNotes 的三条内置配方 latte / cold / pour、用户新建的 u_N 配方和收藏引用保存到 Preferences；真正该重构的，是谁有权修改数据，以及修改成功究竟意味着什么。如果每个