HarmonyOS 应用上架预检怎么避免反复驳回：六大质量项变成可执行证据矩阵

团队说“已经测过”，提交后仍因兼容性、隐私或稳定性问题被驳回。原因通常不是完全没测试，而是测试结果没有绑定版本、设备、场景和可复核证据，审核问题回来后也无法确认修复是否覆盖同一条件。

验证边界：资料核对日期为 2026-09-26。本文以华为开发者官网当前可访问的 HarmonyOS 7（API 26）资料为能力边界，代码中的纯函数和状态转换在 Node.js 宿主环境做过断言。当前本机仍是 API 24 SDK，且没有连接 HDC 真机，所以不把宿主断言写成 API 26 编译或真机实测。涉及系统窗口、设备形态、GPU、网络、相机或 3D 重建的接口，正式交付前仍要在 API 26 SDK 与对应真机上补齐编译、日志、性能和异常路径证据。

先复现：不要一上来就改参数

先把触发条件写成可以重复执行的步骤，至少记录系统版本、设备形态、前后台状态和输入数据。一次正常截图不能证明问题已经解决；必须同时保留失败路径、恢复路径和最终状态。团队说“已经测过”，提交后仍因兼容性、隐私或稳定性问题被驳回。原因通常不是完全没测试，而是测试结果没有绑定版本、设备、场景和可复核证据，审核问题回来后也无法确认修复是否覆盖同一条件。

根因与工程模型

以发布版本为主键建立六轴证据矩阵：每个风险项包含适用设备、前置条件、操作步骤、预期结果、日志或录像、责任人和复测结论。高风险项必须有失败路径，例如权限拒绝、离线、低内存和窗口形态切换。只有同一构建产物的必需项全部闭环，才允许进入提审。

把判断集中在纯函数中，页面只负责采集事实和渲染结果。这样既能在没有真机时验证核心状态转换，也能在接入 API 26 接口后用同一组事件序列回归。

type Axis='COMPAT'|'STABILITY'|'PERFORMANCE'|'POWER'|'SECURITY'|'UX';
interface Evidence { axis:Axis; build:string; passed:boolean; artifact?:string; risk:'HIGH'|'MEDIUM'|'LOW' }
export function releaseReady(items:Evidence[],build:string){
  const current=items.filter(x=>x.build===build);
  return current.length>0 && current.every(x=>x.passed && (x.risk!=='HIGH' || !!x.artifact));
}

案例一：稳定路径也要验证

权限首次拒绝后再次进入核心页面，应用曾直接白屏。稳定性与 UX 两个轴分别记录：前者验证不崩溃，后者验证解释和重新授权路径可达，不能用一张“页面正常”截图同时代替。

复现记录需要包含输入、关键状态迁移和最终输出。若实际接口回调顺序与预期不同，应先更新事件模型，而不是在页面里继续叠加延时。

案例二：异常与恢复路径

折叠屏从展开切到悬停态时布局遮挡。兼容性轴记录设备形态和窗口尺寸，性能轴同时记录切换期间是否连续掉帧；修复后使用同一构建号复测并关联录像。

异常路径验收不能停在“没有崩溃”。还要确认用户看见什么、是否可以继续、重复操作会不会产生副作用，以及恢复后状态是否与首次成功一致。

方案对比

观察项	容易出问题的做法	更可靠的做法
测试结论	一句“已测试”	版本化六轴证据矩阵
风险场景	只跑成功路径	权限拒绝、离线、低内存等失败路径
构建一致性	不同包结果混用	所有证据绑定同一 build
整改闭环	改完重新截图	原条件复现、修复与回归关联

更可靠的方案共同点是：状态有名字、输入有边界、失败可恢复、结果可读回。封装时把系统能力适配层、纯状态层和页面层分开，后续官方接口变化只替换适配层，不把业务判断散落到组件回调。

上线前检查表

• 六大核心质量均有责任人与结论。
• 高风险项有日志或录像证据。
• 所有证据绑定同一提交构建。
• 失败路径不被成功截图替代。
• 审核问题可回溯到原场景并复测。

官方资料与适用范围

• HarmonyOS 开发者测试服务
• 提交 HarmonyOS 应用

官方资料负责说明能力范围，本文代码负责解释工程控制逻辑。由于本机尚未具备 API 26 SDK 与对应真机，正式项目必须补齐接口签名、权限、设备支持范围和真实性能证据后再交付。

结论

这个问题的关键不是再加一个 if，而是把系统信号转换成稳定、可测试、可恢复的业务状态。先复现、再建模、最后用两条不同路径验证，才能让新能力从演示效果变成可长期维护的工程能力。