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-nconsole\.(log|info|debug)|hilog\.|TODO.*release|USE_MOCK|mockentry features common rg-ntoken|authorization|phone|location|photo|passwordentry 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 与诊断开关模块 ownerrelease 搜索与真机主路径当每项都有 owner发布自查就不会在最后一天变成一次没有边界的大扫除。构建成功后还要检查产物身份构建日志显示成功只说明任务完成。交付前要确认拿到的是目标模块、目标签名和目标版本的 HAP而不是旧目录中的历史文件。将产物路径、生成时间、版本信息记录在 release note 中交接时就不会出现“上传了上一次包”的低级错误。检查目的HAP 输出路径排除历史产物混淆包名与版本确认覆盖/升级关系签名与构建类型确认适用于测试或发布文件哈希需要时确认交接文件未被替换如果当前会话未实际生成 release 包就把它标为待执行而不要以源码检查代替构建结论。权限与最小使用范围一起复核每个requestPermissions条目都应对应一个用户可见功能和清晰用途文案。已经不使用的权限应移除需要权限的功能应在用户触发时再请求并为拒绝设计安全的替代路径。发布检查可以把配置、入口、用途和拒绝后的行为放在同一表中核对。权限触发功能用途说明拒绝后的路径相机拍摄头像拍摄个人头像从相册选择定位附近服务显示附近内容手动选择地区这能减少“配置里有权限、产品里找不到用途”以及“入口存在、拒绝后黑屏”的双重风险。版本升级路径必须模拟一次发布包不是只装到一台空设备上。至少用已有数据的旧版本覆盖安装一次检查本地数据、路由恢复和缓存版本是否正常再用全新安装检查首启流程。两个场景分别暴露迁移问题和首次初始化问题不能互相代替。若项目尚不具备升级测试环境应在交付说明中写为明确风险并指定责任人和后续验证方式。诚实的未验证项比模糊的“已自查”更有价值。安装方式核对重点全新安装首启、协议、默认资源、空态覆盖安装数据兼容、缓存版本、路由恢复卸载后重装本地数据是否按产品预期清除目标设备安装图标、启动、权限与主任务对每种方式记录设备、系统版本和结果。这样出现安装差异时团队能迅速区分是包问题、迁移问题还是目标设备差异。失败项要形成明确的阻断或豁免结论检查中发现问题时不要只把它留在聊天记录里。给每项标注是否阻断交付、临时豁免原因、责任人和复核时间。例如 release 构建失败、隐私入口不可达、敏感日志未清理通常应阻断某款未覆盖机型的视觉微调可在负责人确认后作为已知风险。[阻断] release HAP 构建失败模块 A 缺少资源引用修复后重跑构建 [风险] 平板横屏截图待补不影响手机交付负责人 XXX复核日期 YYYY-MM-DD这种记录让发布决定可审计也能防止“以为别人已经处理”导致的问题重新进入下一版。发布流程还应保留最小回滚信息上一稳定包的版本、当前包的构建来源、变更摘要和出现严重问题时的处置方式。回滚不是鼓励草率发布而是让团队在真实设备或商店环境发现阻断问题时有明确选择。没有回滚线索时任何线上问题都会变成临时排查影响用户的时间也会更长。当应用包含账号、本地数据或重要业务记录时回滚前特别要确认数据格式是否向后兼容。若新版本已经写入旧版无法理解的数据简单降级包可能带来二次问题这类风险应在版本设计和升级验证阶段提前处理。把发布检查放进每个版本节奏而不是临近提审才开始问题成本会显著降低。持续复盘清单命中项下一次交付才会更可靠。做到可追溯。