API Change Assistant 扫完就结束？HarmonyOS 7 升级真正缺的是一张可关闭的风险账本

API Change Assistant 能定位 ArkTS 或 C API 的行为变化，并提供代码位置和适配链接，但“扫描完成”不等于“升级完成”。如果结果只停在工具面板里，团队很快会丢失负责人、影响场景和验证证据。官方升级指南还要求在新旧设备上做兼容测试，因此扫描结果必须进入一张可以逐条关闭的风险账本。

先把边界说明白

关注点	应该怎么理解	容易踩的坑
扫描命中	代码使用了发生变化的 API	不等于线上一定受影响
场景确认	判断 target、模型和调用路径	决定修复优先级
关闭证据	代码变更 + 编译 + 新旧版本验证	缺一项就不能标记完成

这张表不是把官方文档换一种说法，而是把接口边界变成能检查的工程条件。适配前先确认当前应用是否命中条件，再决定是否改代码。没有命中的模块不应为了“统一写法”一起重构，命中的模块也不能只改到编译不报错。

案例一：把扫描行转换为稳定风险编号

导出结果后，用“模块、API、代码位置、变更类型”生成稳定键。重复扫描时合并同一项，而不是每天创建新的任务。只有代码位置真实移动时，更新位置但保留历史处理记录。

type ScanHit = { module: string; api: string; file: string; kind: string };
function riskKey(hit: ScanHit): string {
  return [hit.module.trim(), hit.api.trim(), hit.file.replace(/\/g, '/'), hit.kind.trim()].join('|');
}
const a = riskKey({ module: 'ArkUI', api: 'Example', file: 'entry\src\A.ets', kind: 'behavior' });
const b = riskKey({ module: 'ArkUI', api: 'Example', file: 'entry/src/A.ets', kind: 'behavior' });
if (a !== b) throw new Error('同一风险未合并');

这一段先验证外围决策。它的价值是让输入和结果可重复，不依赖页面当前碰巧处于什么状态；接入 ArkUI 或系统能力时，再把结果映射成实际节点、路由或接口调用。

案例二：关闭条件不能只写“已修改”

风险状态至少区分未分析、需要修改、待 API 26 编译、待设备验证和已关闭。纯逻辑测试通过只能推进到编译阶段，不能跳过设备验证；确实不受影响的命中要写明触发条件为何不存在。

type Evidence = { analyzed: boolean; codeChanged: boolean; api26Build: boolean; oldDevice: boolean; newDevice: boolean };
function riskStatus(e: Evidence): 'new'|'fixing'|'verify'|'closed' {
  if (!e.analyzed) return 'new';
  if (!e.codeChanged) return 'fixing';
  if (!e.api26Build || !e.oldDevice || !e.newDevice) return 'verify';
  return 'closed';
}
if (riskStatus({ analyzed:true, codeChanged:true, api26Build:true, oldDevice:false, newDevice:true }) !== 'verify') throw new Error('旧设备证据被跳过');

第二个案例故意覆盖与第一个不同的失败条件。真实工程还应加入快速重复操作、前后台切换、窗口尺寸变化、空数据和恢复路径，避免只验证一次成功流程。

为什么选择这种做法

手工全局搜索会漏掉间接调用，单靠扫描又会忽略产品触发条件。推荐工具扫描负责发现，风险账本负责决策和证据；每次 SDK 更新重新扫描并对比新增、消失和位置变化，才能让升级进度可审计。

如果团队准备封装，建议把公开接口保持在“输入事实、输出决策”的层级，不让调用方直接依赖底层节点对象。这样既方便复用，也便于写断言；需要系统能力的部分留在薄薄的适配层，升级时更容易定位。

怎样验证，哪些结论还不能提前说

先把验证分成三层。第一层是纯逻辑：输入、状态转换和边界条件可以在宿主环境运行断言；第二层是 API 26 编译：检查接口签名、系统能力和模型约束；第三层才是目标设备：检查触摸、键鼠、屏幕朗读、横竖屏、窗口缩放和前后台恢复。三层证据不能混在一句“已经跑通”里。

当前示例中的纯 TypeScript 决策函数可以独立测试，用于证明分支没有自相矛盾；涉及 ArkUI 节点、系统手势、跨设备能力和系统服务的片段，仍要使用 API 26 SDK 编译，并在支持该能力的 HarmonyOS 7 设备或云调试设备上验收。这样写不是保守，而是避免把没有发生过的真机结果当成事实。

动态页面还要观察状态变化后的第二次结果：首次进入正确，不代表弹窗关闭、列表更新或窗口缩放后仍然正确。每次状态切换都应重新核对当前节点、焦点目标、返回路径和数据快照，避免旧缓存继续影响新页面。

建议每次留下以下记录：

• DevEco Studio、SDK、targetSdkVersion 和设备系统版本。
• 触发输入、页面层级、窗口尺寸、操作方式与最终状态。
• 正常路径、空数据、快速重复操作、旋转或窗口缩放后的结果。
• 屏幕朗读、字体放大、深浅色和键盘焦点是否仍然可用。
• 性能对照使用同一批数据、同一设备状态和同一测量区间。

可以复用成什么

不要把适配判断散落在页面 Builder 中。更稳的结构是“能力探测或尺寸输入 -> 纯函数决策 -> 页面渲染 -> 设备证据”。纯函数负责输出稳定的布局或交互意图，页面只消费结果；下一次系统升级时，优先修改边界层和测试样本，不必把所有页面重新翻一遍。

发布前自查

• 文章讨论的是 HarmonyOS 7 / API 26 当前资料，不拿旧版本页面替代新接口。
• 两个案例的输入、失败现象和解决目标不同，不是同一段代码换名称。
• 代码中的常量有来源；没有来源的数值明确写成示例策略，不伪装成系统规定。
• 性能、兼容性与无障碍结论都有可重复的检查方法。
• 日志不保存账号、文件内容、设备标识和其他敏感数据。

官方资料

• HarmonyOS 7 API 26 升级适配指南
• HarmonyOS 开发者文档中心