Atomics.waitAsync 必须在 Worker 中使用且需跨源隔离，因主线程禁用 SharedArrayBuffer 防御 Spectre；验证需 typeof SharedArrayBuffer 和 Atomics.waitAsync 均为 true；Worker 中须先 load 再 waitAsync，notify 需匹配索引与时机，并建议双状态模式防丢失。
Atomics.waitAsync 不能在主线程使用，这是硬性限制。你必须把它放进 Worker 里，否则直接抛 TypeError: Atomics.waitAsync is not supported —— 这不是兼容性问题，是浏览器策略层面的禁用。
为什么主线程调用 Atomics.waitAsync 一定失败
根本原因不是 API 没实现，而是它依赖 SharedArrayBuffer，而现代浏览器默认禁用 SharedArrayBuffer 防御 Spectre 类攻击。即使你手动 new SharedArrayBuffer(4) 成功了，只要页面没启用跨源隔离（COOP/COEP），Atomics.waitAsync 就不可用，且错误提示非常不友好，只报类型错误，不提隔离策略。
验证是否就绪，得在控制台跑这两句：
typeof SharedArrayBuffer !== 'undefined' typeof Atomics.waitAsync === 'function'
两者都为 true 才算过关。本地开发时，file:// 协议绝对不行，必须起 HTTP 服务，比如：
python3 -m http.server 8000 --bind 127.0.0.1
同时确保响应头包含：
Cross-Origin-Opener-Policy: same-originCross-Origin-Embedder-Policy: require-corp
Worker 中初始化共享内存与等待逻辑的正确写法
主线程负责创建和传递，Worker 负责绑定视图并调用 waitAsync。关键点在于：等待前必须先读一次值，否则可能错过初始状态变化；waitAsync 必须写在 async 函数里，不能裸 await。
主线程示例：
const sab = new SharedArrayBuffer(4);
const iv = new Int32Array(sab);
iv[0] = 0; // 初始值
const worker = new Worker('worker.js');
worker.postMessage({ sab });
Worker 内部（worker.js）：
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
let iv;
self.onmessage = async (e) => {
iv = new Int32Array(e.data.sab);
// 必须先 load 确认当前值，再 wait
if (Atomics.load(iv, 0) === 0) {
const { value, asyncId } = await Atomics.waitAsync(iv, 0, 0);
if (value === 'ok') {
console.log('被通知，新值：', Atomics.load(iv, 0));
}
}
};
注意：iv 必须是 Int32Array，不能是 Uint32Array 或其他类型视图，字节偏移和类型必须严格一致，否则原子操作失效。
Atomics.notify 怎么配才不会让 waitAsync 永远挂起
waitAsync 不是轮询，它交由底层线程调度器挂起等待，唤醒全靠 notify。一旦漏掉、错位或数量不匹配，就会永远 pending。
通知方（通常是主线程或另一个 Worker）必须满足三个条件：
- 在同一个
SharedArrayBuffer上构造的Int32Array视图 - 调用
Atomics.notify(iv, 0, 1)—— 第二个参数是索引（必须和waitAsync的位置一致），第三个参数是唤醒数量（1表示只唤醒一个等待者） -
notify必须发生在waitAsync调用之后、且该等待尚未被 resolve 前；如果先notify后waitAsync，这次通知就丢了
强烈建议加超时保护：
const result = await Promise.race([
Atomics.waitAsync(iv, 0, 0),
new Promise((_, reject) => setTimeout(() => reject(new Error('timeout')), 5000))
]);
容易被忽略的底层一致性细节
最隐蔽的问题不是语法或配置，而是内存顺序和竞态窗口。比如主线程改值后立刻 notify，但 Worker 还没执行到 Atomics.load(iv, 0)，就可能跳过初始值检查，导致 waitAsync 等待一个永远不会变的旧值。
所以实际工程中，推荐用“双状态”模式：一个位置存数据，另一个位置当信号位。例如：
- 位置 0 存业务值
- 位置 1 当信号（0=未就绪，1=已就绪）
- Worker 先
Atomics.load(iv, 1) === 0，再waitAsync(iv, 1, 0)，通知方改iv[1] = 1后notify(iv, 1, 1)
这样能彻底规避“先改值后等待”导致的丢失问题。原子操作本身不解决逻辑时序，只保证单次读写不撕裂 —— 时序得靠你设计。
