24-发布包被临时内容拖累-用资源日志隐私清单做提交前自查
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))这段路由只是入口示例；交付前还要验证页面实际打开、返回正确，并确认协议内容由业务/法务确认。
用真机主路径做最后确认
- 首次启动：启动图、同意流程、空态正常。
- 主任务：登录或本地进入、创建、保存、返回、再次打开。
- 异常路径：拒绝权限、断网、无数据。
- 设置路径：主题、隐私政策、退出或清数据。
- 重启应用：关键数据和路由恢复符合预期。
交付说明只陈述已证明的事实
| 写法 | 是否合格 |
|---|---|
“已运行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这种记录让发布决定可审计，也能防止“以为别人已经处理”导致的问题重新进入下一版。
发布流程还应保留最小回滚信息：上一稳定包的版本、当前包的构建来源、变更摘要和出现严重问题时的处置方式。回滚不是鼓励草率发布，而是让团队在真实设备或商店环境发现阻断问题时有明确选择。没有回滚线索时，任何线上问题都会变成临时排查，影响用户的时间也会更长。
当应用包含账号、本地数据或重要业务记录时，回滚前特别要确认数据格式是否向后兼容。若新版本已经写入旧版无法理解的数据，简单降级包可能带来二次问题；这类风险应在版本设计和升级验证阶段提前处理。
把发布检查放进每个版本节奏，而不是临近提审才开始，问题成本会显著降低。
持续复盘清单命中项，下一次交付才会更可靠。
做到可追溯。