sharedarraybuffer需跨域隔离环境启用，且仅限worker中使用atomics.wait/notify等操作；其内存共享需配合原子操作与显式通知机制，避免线程阻塞和内存泄漏。
SharedArrayBuffer 必须配合跨域策略启用
浏览器默认禁用 SharedArrayBuffer，直接 new 会抛出 TypeError: SharedArrayBuffer is not enabled。这不是代码写错了，而是安全策略限制——它可能被用于幽灵漏洞（Spectre）类攻击，所以现代浏览器要求页面运行在跨域隔离环境中。
实操上必须同时满足两个条件：
- 服务器响应头包含
Cross-Origin-Embedder-Policy: require-corp和Cross-Origin-Opener-Policy: same-origin - HTML 中的
<iframe></iframe>、<script></script>等资源需显式声明crossorigin属性（例如<script crossorigin src="worker.js"></script>） - 本地开发时不能靠
file://协议打开，得用localhost或127.0.0.1启服务（比如npx serve）
Atomics.wait() 和 Atomics.notify() 不是 sleep/wake 的简单替代
很多人以为 Atomics.wait() 就是“让线程睡几毫秒”，其实它只在 SharedArrayBuffer 的某个整数位置值未变时才挂起，并且**必须配合 Atomics.notify() 才能唤醒**——它不是定时器，也不是轮询开关。
典型误用场景：
- 在主线程调用
Atomics.wait()：不支持，会直接报TypeError: wait not allowed on main thread - 传入非
Int32Array视图（比如Float64Array）：报错RangeError: view is not an Int32Array - 等待值与当前值不等：函数立即返回
"not-equal"，不会挂起
正确用法示例（Worker 内）：
const sab = new SharedArrayBuffer(4); const ia = new Int32Array(sab); Atomics.store(ia, 0, 0); // 初始化为 0 Atomics.wait(ia, 0, 0, 1000); // 等待位置 0 的值变为非 0，最长 1000ms
Atomics.add() / .sub() / .and() 等操作天然线程安全，但别滥用
这些函数对共享内存的读-改-写是原子的，不需要额外锁。但要注意它们只作用于 Int32Array 或 BigInt64Array，且目标索引必须在视图范围内。
常见陷阱：
- 用
Atomics.add(ia, 0, 1)模拟计数器没问题，但若想“先读再判断再写”，就不能拆成Atomics.load()+if+Atomics.store()——中间可能被其他线程插入修改，必须用Atomics.compareExchange() -
Atomics.or()对布尔标志位做“置位”可以，但Atomics.load()返回的是数值，不是布尔值，别直接if (Atomics.load(ia, 0))当真/假用（0 是 false，非 0 是 true，逻辑没错，但语义模糊） - 所有
Atomics操作都要求视图基于SharedArrayBuffer，传入普通ArrayBuffer会静默失败或报错
Worker 通信仍需 postMessage，SharedArrayBuffer 只共享数据不共享逻辑
SharedArrayBuffer 让多个 Worker（或主线程+Worker）看到同一块内存，但它不提供任何消息通知机制。你不能靠“改了共享内存就自动触发对方执行某函数”——这得自己用 Atomics.notify() + Atomics.wait() 配合轮询或事件循环来模拟信号。
实际协作模式通常是：
- 用一个固定位置（如
ia[0]）作状态码：0=空闲，1=任务中，2=完成 - Worker 改完结果后，
Atomics.store(ia, 1, result)写入数据，再Atomics.store(ia, 0, 2)更新状态，最后Atomics.notify(ia, 0) - 主线程用
Atomics.wait(ia, 0, 2)等待完成态，醒来后读ia[1]
注意：Atomics.wait() 会阻塞 Worker 线程，所以务必确保有配套的 notify()，否则线程永久挂起。
最易被忽略的一点：SharedArrayBuffer 的生命周期由所有持有它的对象共同管理，只要还有一个 Int32Array 引用它，GC 就不会回收——忘了清理视图引用会导致内存泄漏，尤其在频繁创建/销毁 Worker 的场景里。
