HarmonyOS 发布前别靠记忆：资源、日志、隐私和构建结果一次收口

摘要：主流程能跑并不意味着可以交付。发布包常被测试入口、占位资源、敏感日志、不可达的隐私入口和未验证的 release 构建拖住。本文给出一套可执行的提交前检查顺序：先构建，再扫临时内容，再核资源、路由和隐私，最后用真机主路径确认结果与剩余风险。

一次典型返工是：功能都通过了，提交前才发现启动图仍是旧图、日志打印了接口字段、隐私协议只在首次弹窗出现。问题不在某个开发“粗心”，而在没有把发布检查变成可复查的交付物。

先定义“本次交付检查什么”

类别	必查项	产出
包信息	包名、版本号、模块配置	配置复核记录
构建	release HAP 编译	成功日志或错误清单
资源	图标、启动图、空态、深色资源	资源路径确认
日志与 mock	临时开关、样例数据、敏感字段	搜索结果处置
隐私与路由	协议入口、权限说明、返回路径	真机操作记录

清单不是“都看过了”的口头承诺，每一项都需要一个可追溯结果。

先跑交付构建，再处理其余项

.\hvigorw.bat assembleHap --no-daemon

调试包正常不等于交付包可用。构建失败先修失败，警告则区分是否影响发布；不要把没有运行过的命令写成“已验证”。

包版本和配置要与交付目标一致

{
  "app": {
    "bundleName": "com.example.learning",
    "versionCode": 102,
    "versionName": "1.0.2"
  }
}

复核实际工程中的 AppScope/app.json5、模块名和签名配置。版本号、包名和升级路径属于发布边界，不应由业务页面临时拼接或猜测。

用固定搜索找临时内容

rg -n "console\.(log|info|debug)|hilog\.|TODO.*release|USE_MOCK|mock" entry features common
rg -n "token|authorization|phone|location|photo|password" entry features common
rg --files | rg "(test|debug|mock|placeholder|temp)"

搜索命中不等于必须全部删除：保留的诊断日志应说明用途且不含敏感信息；mock 必须从 release 主路径退出。逐条标记“删除、降级、保留原因”，不要一键静默处理。

资源和路由都要从用户入口验证

项目	核对方式
应用图标、启动图	检查 AppScope 与 Ability 配置实际引用
深色模式资源	切换系统主题观察对比度
主要页面入口	从可见按钮进入并返回
空态与错误态	断网、无数据时检查文案和图片
返回栈	逐层返回，不出现空页或错 Tab

仅检查文件存在不够；资源必须在最终打包的真实入口中被使用。

隐私入口不能只在首次弹窗出现

隐私政策、用户协议和权限用途说明应在设置页或个人页长期可达。请求相机、定位等权限前，文案与实际用途应一致；日志与导出能力也要确认没有扩大数据暴露面。

Button('隐私政策')
  .onClick(() => this.navPathStack.pushPathByName('PrivacyPolicy', undefined))

这段路由只是入口示例；交付前还要验证页面实际打开、返回正确，并确认协议内容由业务/法务确认。

用真机主路径做最后确认

1. 首次启动：启动图、同意流程、空态正常。
2. 主任务：登录或本地进入、创建、保存、返回、再次打开。
3. 异常路径：拒绝权限、断网、无数据。
4. 设置路径：主题、隐私政策、退出或清数据。
5. 重启应用：关键数据和路由恢复符合预期。

交付说明只陈述已证明的事实

写法	是否合格
“已运行 assembleHap --no-daemon，结果成功”	合格
“已检查隐私入口，设置页可打开”	合格
“应该没有敏感日志”	不合格
“已修完，没跑构建”	应明确为未验证

小结

发布前检查的价值，是用固定步骤替代临场记忆：构建给出包的事实，搜索暴露临时内容，资源和路由回到用户入口，隐私入口保证长期可达。清单完成后再交付，剩余风险也应如实写出。

把检查结果写成可交接的 release note

一个简短的交接文件能让测试、发布和下一位维护者知道哪些是已验证事实，哪些仍需真机或上架环境确认。

## 1.0.2 交付检查
- 构建：`hvigorw assembleHap --no-daemon` 已通过
- 资源：图标、启动图、深色空态已从真实入口确认
- 隐私：设置页可打开隐私政策；相机用途文案已复核
- 待人工确认：目标机型安装、签名与商店侧资料

release note 不需要写成长报告，但不能把“源码看起来没问题”替代为验证结论。尤其签名、上架表单、目标机型兼容性如果没有实测，应明确列为待确认。

对敏感日志做最小化处理

开发期常见的错误是为了排查方便直接打印完整请求、响应或用户对象。发布前应改为带业务标签和错误码的最小日志，并确认调试开关不会在 release 路径打开。

this.logger.warn('network', 'load course failed', {
  code: businessError.code,
  entry: 'course_detail'
})

该日志足够回答“哪个入口、哪类失败”，却不包含 token、手机号、位置、照片路径或服务端返回体。若问题必须采集更详细信息，应先经过明确的隐私与安全评审。

资源 owner 与模块 owner 一起签收

资源不是“设计给了就结束”。图标归 AppScope 或模块配置、页面插图归 feature 资源、协议文案归隐私 owner、启动路由归产品层。发布前按 owner 复核可以快速发现资源放错模块、模块打包却未引用、或深色版本遗漏的情况。

交付物	建议 owner	验证动作
图标与启动图	产品/应用层	安装后首次启动
页面插图与空态	feature owner	正常与无数据场景
隐私政策与用途文案	隐私 owner	设置入口与权限触发
mock 与诊断开关	模块 owner	release 搜索与真机主路径

当每项都有 owner，发布自查就不会在最后一天变成一次没有边界的大扫除。

构建成功后还要检查产物身份

构建日志显示成功，只说明任务完成。交付前要确认拿到的是目标模块、目标签名和目标版本的 HAP，而不是旧目录中的历史文件。将产物路径、生成时间、版本信息记录在 release note 中，交接时就不会出现“上传了上一次包”的低级错误。

检查	目的
HAP 输出路径	排除历史产物混淆
包名与版本	确认覆盖/升级关系
签名与构建类型	确认适用于测试或发布
文件哈希（需要时）	确认交接文件未被替换

如果当前会话未实际生成 release 包，就把它标为待执行，而不要以源码检查代替构建结论。

权限与最小使用范围一起复核

每个 requestPermissions 条目都应对应一个用户可见功能和清晰用途文案。已经不使用的权限应移除；需要权限的功能应在用户触发时再请求，并为拒绝设计安全的替代路径。发布检查可以把配置、入口、用途和拒绝后的行为放在同一表中核对。

权限	触发功能	用途说明	拒绝后的路径
相机	拍摄头像	拍摄个人头像	从相册选择
定位	附近服务	显示附近内容	手动选择地区

这能减少“配置里有权限、产品里找不到用途”以及“入口存在、拒绝后黑屏”的双重风险。

版本升级路径必须模拟一次

发布包不是只装到一台空设备上。至少用已有数据的旧版本覆盖安装一次，检查本地数据、路由恢复和缓存版本是否正常；再用全新安装检查首启流程。两个场景分别暴露迁移问题和首次初始化问题，不能互相代替。

若项目尚不具备升级测试环境，应在交付说明中写为明确风险并指定责任人和后续验证方式。诚实的未验证项比模糊的“已自查”更有价值。

安装方式	核对重点
全新安装	首启、协议、默认资源、空态
覆盖安装	数据兼容、缓存版本、路由恢复
卸载后重装	本地数据是否按产品预期清除
目标设备安装	图标、启动、权限与主任务

对每种方式记录设备、系统版本和结果。这样出现安装差异时，团队能迅速区分是包问题、迁移问题还是目标设备差异。

失败项要形成明确的阻断或豁免结论

检查中发现问题时，不要只把它留在聊天记录里。给每项标注是否阻断交付、临时豁免原因、责任人和复核时间。例如 release 构建失败、隐私入口不可达、敏感日志未清理通常应阻断；某款未覆盖机型的视觉微调可在负责人确认后作为已知风险。

[阻断] release HAP 构建失败：模块 A 缺少资源引用，修复后重跑构建
[风险] 平板横屏截图待补：不影响手机交付，负责人 XXX，复核日期 YYYY-MM-DD

这种记录让发布决定可审计，也能防止“以为别人已经处理”导致的问题重新进入下一版。

发布流程还应保留最小回滚信息：上一稳定包的版本、当前包的构建来源、变更摘要和出现严重问题时的处置方式。回滚不是鼓励草率发布，而是让团队在真实设备或商店环境发现阻断问题时有明确选择。没有回滚线索时，任何线上问题都会变成临时排查，影响用户的时间也会更长。

当应用包含账号、本地数据或重要业务记录时，回滚前特别要确认数据格式是否向后兼容。若新版本已经写入旧版无法理解的数据，简单降级包可能带来二次问题；这类风险应在版本设计和升级验证阶段提前处理。

把发布检查放进每个版本节奏，而不是临近提审才开始，问题成本会显著降低。

持续复盘清单命中项，下一次交付才会更可靠。

做到可追溯。