同样都是“保存”，为什么筛选条件写到 Preferences、票据记录写到 RDB，而票据图片以后还可能落到应用文件目录？读到系列收尾，如果仍把这三种存储视为可以随意互换的工具，前五篇费力建立的异常恢复机制就失去了价值。最后一篇换一种方式，不从单个接口的使用说明开始，而从应用的三类真实数据反推存储选型，并用一个归档操作把全链路串起来。 票据归档助手已经有稳定的配置协议：Preferences 文件

交付前最后一次检查，不应该从“界面好不好看”开始，而应该从一个更难回答的问题开始：当作品被移除、版次发生变化、旧分页结果迟到时，图稿校对台还能不能把人带到正确的审阅位置？ 如果答案依赖某个页面恰好没有销毁，或者恰好没触发并发加载，这套方案还没真正收尾。 这篇延续此前五个阶段的工程约定。SketchWork 的稳定身份是 id；SketchRevision 以 revisionId 关联 workI

应用已经能在模拟器里启动，开发者很容易以为离上架只差点击一个“上传”按钮。实际进入发布环节时，最容易耽误进度的往往不是某个 ArkUI 组件，而是三件看起来不起眼的东西：包名与注册应用不一致、构建时仍使用调试签名、版本信息与已经发布的包冲突。更麻烦的是，有些工程在本机可以安装 HAP，却拿着同一个文件准备提交应用市场，直到平台校验时才发现产物类型根本不对。 本文面向一个已经完成页面功能的小型 Ha

一条任务从列表走到详情，再回到列表，看起来不过两次页面切换。可一旦加入筛选、任务删除、快速重复点击、单实例目的页复用，这条路径就不再是“点进来、退回去”那么简单：有时候返回后状态是旧的，有时候详情显示了上一条任务，还有时候用户只做了一次操作，列表却重复刷新。要判断这套页面任务流能否交付，不能再只检查导航动画是否流畅，而要检查输入、业务修改、输出和异常路径是否守住同一份契约。 前三篇已经定下工程骨架

“把归档票据也塞进 Preferences，省得维护数据库”，这个建议听起来很有吸引力。毕竟前四篇已经实现了筛选配置的版本迁移、校验、串行写入和前后台恢复，再往 JSON 里加一个票据数组，似乎马上就能显示列表。然而数据模型的边界不是以“能不能保存”为准，而是要看查询、修改、生命周期与失败恢复的职责是否相同。筛选偏好是用户的选择，票据是业务事实。两者即使出现在同一个界面，也不应该使用同一种存储协议

图稿只有十几张时，校对台把所有作品一次性放进数组，页面似乎没有什么问题。到了几百张，问题却悄悄变了：切换筛选条件要重新准备一批数据，滚动过程中又可能不断追加作品，审阅者正在核对的 sk-01 不能因为目录更新而被清空。上一节处理的是单幅作品内部的批注长列表，这次讨论的则是全部图稿的目录列表。二者不是同一个数据源，不能因为都用 LazyForEach 就共享更新逻辑。 我们保留此前建立的 Sketc

一张界面看起来整洁，不等于每个人都能顺畅操作它。假设应用里有一张“费用报销单”卡片：左边是图标，中间是金额和审核状态，右边只有一个小小的勾选符号。开发人员手指轻点就能完成“归档”，而打开屏幕朗读后，用户听到的却可能是“图片”“三百二十八”“已审核”，最后根本不知道该在哪里执行归档。这个问题不在配色是否好看，而在界面有没有把对象的含义与动作告诉辅助服务。 本篇围绕一个独立的报销记录卡片做完整的无障碍

任务列表里点击 tk-101，详情页出现了“核对设计稿”；再从另一个入口点击 tk-102，导航动画结束，标题居然还是“核对设计稿”。刷新列表也没用，仓储中的第二条任务分明存在。问题看起来像数据缓存，实际却藏在导航栈里：页面被复用了，原先只在创建阶段读取一次参数的逻辑没有再次运行。 前两篇已经明确了这套工程的业务边界。任务统一使用 TaskItem(id,title,status,owner)，由

一个票据归档应用，用户在首页打开“仅看待归档”，又改成按日期升序；马上切到其他应用，再回到票据列表。有时页面展示了旧条件，有时刚才点过的设置却已经保存。若把问题简单归为“应用进入后台后没有及时保存”，处理方向很容易走偏。真正要弄清楚的是：页面当前显示的选择、写入队列中等待的修改、以及 Preferences 已经提交的数据，究竟哪一份才算已生效。 这一篇沿用前三篇的数据协议，不会换成另外一种存储。

图稿校对台做到第三阶段，选中作品、版次与批注定位都能在窗口改变后保留下来。然而，当一张图稿从两条批注积累到几百条，新的矛盾就出现了：用户只是把“屋檐透视”改成“已处理”，整个列表却看起来重新闪了一下；拖到第八十条意见再补上一条，滚动位置也不够稳定。此时应该处理的是数据通知和渲染边界，而不是继续叠加保存按钮。 上一阶段已经明确了三类身份：SketchWork.id 表示作品，SketchRevisi