应用的发布配置和权限关系都核对过，打包前却仍可能发生一种不容易察觉的变化：研发同事没有修改业务代码，依赖更新却使构建输入发生了漂移。oh-package.json5中写的是允许范围，安装目录反映的是当前机器取得的结果，实际交付包又属于另一个层次。若把这三处混成“依赖已经检查”，版本回溯时往往找不到差异从何而来。 这次继续完善交付审查工作台。前两篇留下的产品快照和功能权限矩阵保持不变，新增依赖清单、

版本快照整理完成后，下一张经常卡住交付的表是权限表。业务代码里已经删除拍照入口，module.json5却保留了相机权限；另外一个网络上传功能刚刚加入，开发者只检查了页面上能否点按钮，忘记核对模块权限配置。更隐蔽的问题是：同样叫“选择照片”，使用系统图片选择器和在应用内持续管理媒体库不是同一种接入方式，照搬另一套项目的权限清单往往会引入不必要的请求。 本篇延续上一节的交付审查工作台，不重新造一个应

一套HarmonyOS应用从业务开发进入版本交付时，最容易漏看的往往不是页面，而是散落在工程不同位置的配置。一个版本名已经调整，另一处构建产品仍沿用旧包名；某个模块改成了新入口，交付清单却记录着上一版的设备范围。只看界面无法回答“交付的究竟是哪一套配置”。我更倾向于把审查入口放在配置快照上：先收集事实，再按明确的规则检查，最后把问题定位到具体字段，而不是依赖人工逐个打开文件。 这套交付审查工作台与

赛事的初赛甲组完成封榜之后，计分台进入另一种工作状态。工作人员仍要向参赛队伍展示排名、查阅积分和解释同分名次，但这些查询不应重新计算正在变化的工作表，更不能绕过封榜状态发起普通成绩更新。上一篇把未结申诉检查、修订号与最终快照绑定到封榜事务；这一篇处理后续的只读展示与交付前核对，让页面明确区分“仍在处理的实时榜单”和“已经封存的最终榜单”。 为什么封榜后还要核对版本 假设 preliminary-A

保修凭证的附件页经常需要在多种任务之间来回切换：服务人员先查看购机发票，再返回设备信息核对序列号；随后重新进入附件页，希望仍然停留在“票据”分类、保留刚才选中的发票，并在宽屏工作区直接显示详情。如果每次进入都从默认分类重新加载，操作人员得重复查找；更麻烦的是前一次加载尚未结束时切换了凭证，旧结果可能覆盖新页面。前七篇已经完成编号规范化、设备字段约束、重复登记、附件落盘、更换回收、缩略图解码以及容器

一场机器人赛事的初赛结束后，计分员会希望立刻公布最终榜单，但裁判台上可能还有两条计时申诉正在处理中。此时页面显示的分数可以用于内部预览，却不应被误认为已经封存。上一节为成绩修订建立了追加式裁决事件和反向更正链，能解释每一次得分变化；本篇解决新的工程问题：在什么条件下允许把某个赛段从可修改状态切换为封存状态，并保证这次切换和最终榜单来自同一份数据。 单靠按钮前的一次申诉数量查询不够。检查完成之后、真

维修凭证管理到了附件预览这一步，界面宽度开始影响操作路径。手机上选中一张购机票据，再进入详情查看就很自然；窗口变宽后，如果仍把列表和详情拆成两次页面跳转，平板上的空白区域没有被利用，工作人员还要不断返回列表寻找下一张照片。问题的核心并不是多画一个面板，而是宽窄布局改变时，业务选择与解码资源应当保持独立。 前一篇完成了按需创建缩略图和离开页面时释放图像资源。本篇沿用凭证 AB-2048-73、附件身

第五篇把赛事裁决的生效过程固定下来：正式成绩和申诉状态在同一次关系存储事务中写入，榜单按阶段、组别和规则版本重算。这个机制解决了“裁决已经发布而界面仍显示旧分”的一致性问题，随后还有更敏感的情况：组织者发现上一次裁决采用了错误的计时记录，需要把成绩改回去。若直接修改旧事件，或者把历史成绩行覆盖成原值，后续就无法解释某个队伍为什么曾经从90分变成88分、又恢复到90分。 我把这次修改定义为一条新的“

第五篇把购机票据的替换拆成了新文件落地、数据库引用切换和旧文件回收。文件关系稳定以后，新的性能问题才真正露出来：一个凭证可能有发票、设备外观、维修工单、配件照片以及多次补充的签收回执。附件详情页若把每张原图都按完整像素解码，一次列表滚动就会持续扩大内存占用；用户退出页面后，已经解码的图片对象如果仍被缓存持有，下一次进入还会叠加。 这次我把附件展示改成“数据列表与像素资源分开管理”的结构。数据库负责

第四篇把一条有争议的成绩从待复核推进到已裁定，也保存了复核人、裁决意见和版本。这里容易产生一个看似很小、实际影响整个赛场公信力的问题：裁决已经完成，甲组榜单却还显示旧积分；用户切到乙组再返回，又看到另一套排名。原因通常不在排序算法，而在“裁决状态”“正式成绩”“展示榜单”分别更新，没有定义谁是权威数据、什么时候允许发布。 这一节继续使用大学机器人赛事积分台。甲组青峰队原成绩90分，复核后决定更正为