HarmonyOS应用实战-启示散页-10-发布前别只看能运行：用清单把离线、包体、备份和隐私一次核完-平芜编程栈

HarmonyOS应用实战-启示散页-10-发布前别只看能运行：用清单把离线、包体、备份和隐私一次核完

答案之书做到能运行，只说明主流程能走通；发布前还要回答另一组问题：默认题库是否真的打进包里，清数据后能不能恢复，用户自建题库和收藏是否属于本地数据，备份行为和隐私口径是否一致，图标和启动页有没有指向正式资源。轻量离线应用的发布风险不在接口，而在这些容易被忽略的工程细节。

这篇文章会把问题拆成四个可落地的点：

把构建、资源、离线数据、备份、隐私和真机项拆成发布清单。
明确哪些可以用构建证明，哪些必须真机验证。
检查 backup_config、module.json5、图标和 rawfile 的一致性。
给出适合答案之书这种本地应用的 AGC 隐私说明口径。

1. 能跑只是开发态结论

开发机能打开首页，不等于发布包可交付。debug 构建可能引用了临时资源，release 可能开启混淆或资源压缩，真机冷启动也可能暴露默认题库播种问题。发布前要把“能运行”拆成构建、产物、数据、体验和平台材料。

发布前分组： 1. 构建产物：debug / release 2. 离线数据：rawfile 默认题库、Preferences 初始化 3. 资源：图标、启动页、动画图片、截图 4. 用户数据：题库、收藏、历史、备份 5. 平台材料：隐私、包名、签名、版本号

清单分组能避免临发布时只盯一个 HAP 文件，而漏掉用户数据和平台说明。

2. 先跑 debug，再跑 release

debug 构建证明开发态链路没有断，release 构建证明正式产物路径可用。自动化执行时建议使用--no-daemon，避免构建已经完成但终端不返回造成误判。

&'.\hvigorw.bat'assembleHap--no-daemon &'.\hvigorw.bat'assembleHap `-p product=default `-p buildMode=release `--no-daemon

两种构建关注点不同。debug 更适合快速定位源码问题，release 更接近上架产物。

3. rawfile 默认题库要确认在包内

答案之书依赖内置默认题库。如果 rawfile 路径错了，页面可能在开发数据还在时看不出问题，清数据或新装才白屏。发布前要确认default_deck.json在资源目录中，并且启动播种能读到。

constSEED_PATH:string='seed/default_deck.json';constraw:Uint8Array=awaitcontext.resourceManager.getRawFileContent(SEED_PATH);constdecoder:util.TextDecoder=util.TextDecoder.create('utf-8');constseed:SeedDeckJson=JSON.parse(decoder.decodeToString(raw))asSeedDeckJson;

这段读取链路是发布前必须关注的离线数据入口。资源路径错了，后续页面再漂亮也没有候选答案。

4. 包体大小要能解释来源

轻量应用的包体不一定要极限小，但必须知道大文件来自哪里。答案之书的动画和背景图片最容易放大产物，默认题库 rawfile 也要确认大小合理。发布清单里记录 HAP 大小和大资源列表，下一次迭代才能比较。

Get-ChildItem.\entry\build-Recurse-Filter*.hap|Select-ObjectFullName,LengthGet-ChildItem.\entry\src\main\resources-Recurse|Sort-ObjectLength-Descending|Select-Object-First 20 FullName,Length

包体数字本身不是结论，能解释变化来源才是发布清单的价值。

5. 备份配置要和产品承诺一致

答案之书保存用户自建题库、收藏和历史，这些都属于本地用户数据。如果配置了 BackupAbility，就要说明备份恢复的范围；如果不希望某些数据进入备份，也要在配置和隐私口径里说清楚。

{"extensionAbilities":[{"name":"EntryBackupAbility","srcEntry":"./ets/entrybackupability/EntryBackupAbility.ets","type":"backup","exported":false,"metadata":[{"name":"ohos.extension.backup","resource":"$profile:backup_config"}]}]}

BackupAbility 不是配完就算结束。它影响用户对本地数据可恢复性的预期，也影响隐私说明。

6. backup_config 不是孤立文件

allowToBackupRestore的选择要和产品说明一致。答案之书如果承诺用户数据仅保存在本机，同时允许系统备份恢复，就要解释备份属于系统能力，不是应用上传服务器。

{"allowToBackupRestore":true}

配置、能力和隐私口径三者要一致。否则平台审核或用户反馈时，很难解释清楚数据流向。

7. 隐私说明不能因为无网络省略

无网络不代表没有隐私说明。答案之书保存的是用户输入的问题、自建题库和收藏；这些数据即使只在本机，也应该在 AGC 商品页或隐私政策里明确。

隐私口径建议： 本应用不接入自有服务器，不上传用户题库、提问历史或收藏内容。 用户创建和编辑的内容保存在设备本地。 清除应用数据或卸载应用会移除本地内容；如系统备份已开启，恢复范围以系统备份能力为准。

这段口径要避免夸大。没有实际验证过的网络、备份和删除行为，不要写成绝对承诺。

8. 图标和启动页分开核对

上架问题常见在图标链路：应用图标是正式的，但 startWindowIcon 还是临时图；浅色模式正常，深色背景下启动图标看不清。module.json5 里的应用图标、启动图标和背景色要逐项核对。

{"icon":"$media:app_icon","label":"$string:EntryAbility_label","startWindowIcon":"$media:startIcon","startWindowBackground":"$color:start_window_background"}

图标不是一个资源，而是一组入口。应用列表、启动窗口、AGC 素材和截图都要使用正式资产。

9. 真机项必须单独列出

构建通过不能证明冷启动速度、动画帧率、备份恢复和清数据播种。发布清单要把这些列成真机项，已经验证就写结果，没有验证就保留待验证，不要用源码推断体验。

真机验证： 1. 清数据后首次启动，默认题库自动恢复 2. DrawingPage 首次动画不卡顿 3. 切换题库、收藏、历史 Sheet 都能正常刷新 4. 备份恢复后题库和收藏符合产品说明 5. 深色模式下启动图标和首页文字可读

真机项要诚实记录。没有跑过就写待验证，比写成已通过更可靠。

10. 发布自查表要能复用

最后把自查项写成可复用表，而不是每次临时回忆。答案之书后续更新题库、换图片、加功能时，都可以沿着同一张表走一遍。

提交前自查： [ ] debug 构建成功 [ ] release 构建成功 [ ] rawfile 默认题库在新装后可读 [ ] app_icon / startIcon / 截图均为正式资源 [ ] 隐私说明覆盖题库、收藏、历史和备份 [ ] 发布态没有临时日志和测试入口 [ ] 真机剩余项已记录责任人和结果

这张表不是为了流程感，而是为了把发布风险从记忆里拿出来，变成每次都能复查的工程资产。

清单里也要保留“未验证项”。例如备份恢复、低端机动画帧率、深色模式启动页，如果当前没有设备或平台条件，就明确写成待验证，而不是从源码推断已经没问题。交付文档的可信度来自边界清楚，不来自把所有格子都填满。

每次发布后建议把产物大小、版本号、已验证设备和剩余项写回项目文档。下一次发版时，不需要重新猜上次做到了哪里，也能快速判断本次改动是内容更新、资源替换，还是涉及隐私和备份口径的发布风险。

这份记录越具体，下一次回归越省时间。

验证清单

清应用数据后从冷启动进入，确认默认数据、页面状态和日志分支符合预期。
对本文涉及的写路径准备正常、空值、重复、越界四类输入，确认错误停在 Service 或 Repository。
页面返回、重新进入、切换题库、收藏、历史或删除后，确认对应刷新信号触发重新读取。
修改资源或模块归属后重新构建，确认 HAP、HAR、HSP 的依赖方向没有反转。
涉及真机体验、备份恢复、发布素材的内容，单独记录是否已经在设备或平台侧验证。

常见问题与处理

现象	先看哪里	处理方式
新装后首页无题库	rawfile 路径和 SeedLoader 日志	确认 default_deck.json 打包并在 WindowStage 前播种
release 包资源异常	资源是否放错模块或被压缩影响	按模块核对 media/rawfile 和引用路径
隐私说明被质疑	是否说明本地题库、收藏、历史	明确不上传服务器和系统备份边界
启动图标不一致	icon 和 startWindowIcon 是否不同步	逐项核 module.json5 与资源文件