有一个很容易被忽略的场景：焖饭与蒸蛋同时到点，用户恰好把应用切到了后台，再从通知栏回到厨房计时页面。此时页面可能出现两条“已完成”卡片，但仍留着两个定时刷新器；随后用户确认焖饭，另一个已经到期的任务却被当作新提醒再次发送。问题看起来像通知故障，根因却是页面生命周期、快照状态和通知副作用三套时序没有对齐。 KitchenTempo 前五篇已经建立 deadlineMs 截止时间模型、TimerPh

库存台账真正危险的一次故障，未必发生在用户点击“盘点提交”时。有时写入已经结束，页面也显示正确，可下一次冷启动读取到的字符串却不符合现在的数据结构：某条物料的库存成了负数，流水编号重复，或者 rows 根本不是数组。把这样的 JSON 直接当成 SupplyLedgerV2 渲染，轻则列表空白，重则又一次编辑把损坏数据覆盖成新的“正常文件”。 SupplyLedger 前五篇已经解决行级状态同步

在出行票夹里，“看得见三张车票”和“能找到自己要用的那张票”是两回事。正常字号的手机屏幕上，标题、出发地、时间和票据状态可以轻松塞进一张卡片；当用户开启大字号、折叠设备从展开切回窄屏，或者借助屏幕朗读逐项寻找车次时，同一套布局可能突然变得难以使用。TravelDeck 的前三节已做完响应式栅格、RDB v2 本地持久化、条件查询与稳定 ID 详情读取。本节不再更换表、不添加一个实际上尚未接入的验票

一张图片的轮播不难做。麻烦的是用户刚滑到第三张，外部“下一张”按钮却仍以第二张为准；屏幕变窄以后图片被裁成一条窄缝；图库中某个资源名拼错，页面只剩一块毫无解释的空白。对于在 HarmonyOS 上制作作品展示页的开发者来说，决定体验的往往不是轮播动效有多炫，而是哪一个状态具有最终解释权。本篇使用一个与库存台账、厨房计时和票夹完全无关的独立工程 FrameGallery，实现可重复切换的本地三图作品

焖饭与蒸蛋在同一秒结束，手机页面刚恢复显示，两个任务同时变成“已完成”。这时用户最需要知道的是：哪两件事现在要处理、哪一件已经确认，以及继续运行的烤蔬菜还有多久。若页面仍按照创建顺序从上到下展示，真正要处理的项目可能被挤到屏幕下方；若每秒都按剩余时间重新排序，三张卡片又会不断跳位置，反而让人难以点击。通知栏虽然能提供额外提醒，也无法代替应用本身清晰、稳定的任务排序。 KitchenTempo 的前

同一张库存台账，平时领用一盒笔是一笔操作；月底盘点却可能一次调整几十种物料。把盘点表格逐行循环调用上一节的 submit()，看似复用了功能，实际上把“同一张盘点单”拆成许多可分别成功、分别失败的提交。前十行保存成功，第十一行写盘失败，管理员究竟应该重做整张盘点，还是只补最后一行？另一个风险来自“撤销”：当其他人已经在盘点后领用了转接头，界面再允许撤销盘点，就可能把那次合法领用一起覆盖。 Supp

出行票夹最容易被低估的一处交互，不是新增票据，而是“搜索以后打开详情，再返回列表”。设想用户在 TravelDeck 中输入“上海”，打开高铁票的详情，随后清除关键词并旋转屏幕。如果列表原本只依靠数组下标记住选择项，就可能把高亮留在另一张票上；如果详情直接引用被筛选列表的对象，数据重新加载后还可能显示旧内容。两种错误在三条静态样例里很隐蔽，但数据库接入之后会不断出现。 前两节已经完成两项基础：第一

在一块电子签名板上，用户画完第一笔，点了“撤销”，整块画布却仍留着上一笔的影子；再把手机横过来，笔迹跟着页面一起被拉宽。表面看只是一个绘图控件的小毛病，实际上暴露了两种常见的状态设计错误：把 Canvas 像素当作业务数据，以及把屏幕坐标当作签名的永久坐标。如果画布既保存结果，又承担历史记录，撤销、重做和尺寸适配必然互相牵制。 这里设计一个独立的 HarmonyOS InkBoard 练习应用：在

厨房计时器的“到点提醒”很容易看起来已经完成：把秒数减到零，在页面上弹一个提示，再调用一次系统通知接口就行。真正用起来，问题往往出在第二次打开应用时：焖饭明明已经提醒过，用户从后台切回来却又看见同一张到点通知；或者用户拒绝通知授权，屏幕没有任何变化，误以为计时器根本没有结束。时间到期、发送通知、用户确认是三件不同的事，把它们写成一个布尔值，会使恢复逻辑无法解释页面状态。 KitchenTempo

库存台账最容易被忽略的故障，不是页面少显示了一行，而是两次操作都提示成功，最终只剩下一次的结果。假设中性笔原有 8 盒，仓库管理员领走 3 盒，同时另一位操作人员在同一页面快速登记入库 2 盒。若两个异步处理函数都基于最初的 8 盒构造快照，落盘顺序又不受控制，最后可能出现 10 盒或 5 盒，而正确结果应该是 7 盒。这个错误既可能发生在领用与入库之间，也可能发生在用户重复点按保存时。 前面三节