HarmonyOS 7 空间音频回调排查：A→B→A 切换时，仅比较设备 ID 为什么不够

回调返回时检查设备 ID，是常见的防旧结果写回方案。但是路由 A→B→A 时，第一次 A 的结果与第三次 A 的设备 ID 相同，旧结果就可能被误接收。设备身份只能说明来自哪个设备，不能说明来自哪一次请求。

版本与适用范围

空间化能力查询、状态订阅并非 API 26 才首次提供。这里针对 HarmonyOS 7 音频应用适配的异步状态管理，代码是平台无关的顺序实验；不包含头部姿态采样或音频图渲染。

官方参考文档，核对日期：2026-09-14。下面的 JavaScript 实验可以直接用 Node.js 运行；它验证应用侧算法与状态边界，不是已经在 HarmonyOS SDK 或真机上跑通的完整应用。应用接入时，SDK 调用、事件订阅和资源释放应分别验证。

问题是怎样发生的

设备 ID 检查错误地接收 oldA；修订号检查拒绝 oldA 并只接收 newA。这个复现不靠随机延时，顺序固定可重复。

复现不依赖随机等待。测试用固定输入、显式完成的异步结果或明确的状态变化，让错误条件可以重复出现。先保留失败信号，再检查修复后的状态，避免只看“没有抛异常”就认为问题解决。

案例一：A→B→A

设备 ID 检查错误地接收 oldA；修订号检查拒绝 oldA 并只接收 newA。这个复现不靠随机延时，顺序固定可重复。

案例二：同一设备重新查询

没有切换设备也可能因开关改变重新查询。再 begin A 以后，前一次 A 的 ticket 应失效。

实现代码

export class RouteRevisions {
  revision = 0;
  deviceId = '';
  begin(deviceId) {
    this.deviceId = deviceId;
    return Object.freeze({deviceId,revision:++this.revision});
  }
  accept(ticket) {
    return ticket.deviceId === this.deviceId && ticket.revision === this.revision;
  }
}
export function acceptByDeviceOnly(current, ticket) {
  return current.deviceId === ticket.deviceId;
}

运行验证

把上面的实现和下面的测试按顺序放进同一个 example.mjs 文件，使用 Node.js 执行 node example.mjs。测试采用 Node 内置的 assert，不需要第三方依赖。断言失败时进程报错，全部通过时正常退出。

import assert from 'node:assert/strict';
const routes = new RouteRevisions();
const oldA = routes.begin('A');
const middleB = routes.begin('B');
const newA = routes.begin('A');
assert.equal(acceptByDeviceOnly(routes,oldA), true);
assert.equal(routes.accept(oldA), false);
assert.equal(routes.accept(middleB), false);
assert.equal(routes.accept(newA), true);
const repeatedA = routes.begin('A');
assert.equal(routes.accept(newA), false);
assert.equal(routes.accept(repeatedA), true);

核对时不要把输入样本当作性能数据。上述测试已经在 Node.js 环境逐项执行通过，验证的是代码中写出的条件。涉及窗口、材质、音频或系统入口的真实表现，需要另外在适配设备验证。

为什么选择这个方案

这是异步流程里的 ABA 问题。修订号增加每次操作的身份，不需要保留整段历史。还可以使用每次请求独立对象的引用相等性，但跨模块日志更适合打印数值修订号。

检查项	实验中的做法	接入应用时要补的验证
输入边界	拒绝非法输入或区分失效请求	SDK 返回类型与错误码
状态变化	显式记录每次操作的输入和结果	页面切换、窗口销毁与后台恢复
失败路径	断言旧状态不被错误结果覆盖	弱网、权限拒绝与设备能力缺失
成功路径	检查最终状态，而非只检查无异常	目标设备界面与真实资源行为

真正让旧 A 结果晚到的异步实验

上面的接收条件检查是同步测试。下面再把第一次 A 的结果固定为待完成 Promise，第三次 A 先提交，最后释放第一次 A。两种判断都运行同一个顺序，设备 ID 判断最终保留错误的 old-A，修订号判断保留 new-A。输出值来自真实执行，不是根据代码意图手写的预期日志。

继续在同一个 example.mjs 文件中追加以下代码，使用已经定义的实现和 assert 再运行一次。

export async function runAbaExperiment(accept) {
  const model = new RouteRevisions();
  let releaseOld;
  const oldTicket = model.begin('A');
  let value = 'initial';
  const oldRequest = new Promise(r => {releaseOld = r;}).then(result => {
    if (accept(model,oldTicket)) value = result;
  });
  model.begin('B');
  const latestTicket = model.begin('A');
  if (accept(model,latestTicket)) value = 'new-A';
  releaseOld('old-A');
  await oldRequest;
  return value;
}
assert.equal(await runAbaExperiment(acceptByDeviceOnly), 'old-A');
assert.equal(await runAbaExperiment((model,ticket) => model.accept(ticket)), 'new-A');

接入应用时的取舍

能力查询、开关查询和头部跟踪状态可能有不同的变化来源。不要只在设备 ID 改变时递增修订号；只要当前结果已失效，就应开启新修订。回调携带请求开始时的 ticket，提交时再读取当前状态，不能在返回时临时生成 ticket。日志同时记录 deviceId 和 revision，才能区分“同一个设备又查询了一次”。订阅状态流也要定义初始化快照与增量事件的顺序，防止旧初始化结果覆盖更新后的事件。

封装与复用

把上面的纯逻辑保留为独立模块，界面层只提交输入和消费结果。系统事件适配层负责取得当前窗口、设备或入口的实际数据，不要把测试常量直接搬到正式应用。这样单元测试仍可在没有设备时运行，SDK 接入问题也能和算法问题分开排查。

复用之前先检查实例的作用域：窗口、播放器或请求协调器是否属于同一个会话。复用函数不等于共享所有状态。对于异步回调，需要同时考虑结果失效与底层任务取消；对于同步计算，需要确认单位、取样范围和输入上限。

边界与后续检查

示例仅验证接收条件，不能替代资源取消和订阅解绑。每个播放器或窗口应有自己的修订对象，不应让一个全局计数把无关播放实例的回调互相作废。

回归测试应保留两个案例，再增加空输入、重复入口和生命周期结束后的操作。日志记录输入身份、状态修订与失败原因，不记录敏感内容。升级 SDK 后先检查官方接口签名、支持设备与版本说明，再运行同一组实验和设备回归，避免把旧版本假设带入新环境。