sharedarraybuffer + atomics 可实现多 worker 零拷贝无锁原子通信，但需跨域隔离响应头、crossorigin 加载、transferlist 传递、统一创建共享内存，并严格使用 atomics 方法操作视图。
SharedArrayBuffer + Atomics 能实现多 Worker 间零拷贝、无锁、原子级通讯，但前提是必须绕过浏览器的跨域隔离限制，且所有读写操作都得走 Atomics 方法——直接赋值（arr[i] = 1）会引发竞态，不是“不推荐”，而是“一定出错”。
为什么 SharedArrayBuffer 在本地开发时 new 就报错
这不是语法问题，而是浏览器主动拦截：TypeError: SharedArrayBuffer is not enabled。它默认被禁用，防止 Spectre 类侧信道攻击。
- 必须同时满足两个响应头：
Cross-Origin-Opener-Policy: same-origin和Cross-Origin-Embedder-Policy: require-corp -
<script></script>、<iframe></iframe>、Worker 脚本加载必须带crossorigin属性，比如<script crossorigin src="worker.js"></script> - 不能用
file://协议打开页面；开发时得用localhost或127.0.0.1启服务（如npx serve -l 8080）
postMessage 传 SharedArrayBuffer 的唯一正确写法
传错 buffer 就等于传了个空引用——Worker 收到的是一个普通 ArrayBuffer 拷贝，不是共享内存。
- 主线程发送时，必须把
SharedArrayBuffer实例放进transferList第二个参数：worker.postMessage({ sab }, [sab]) - Worker 内接收后，**不能直接用
new Int32Array(e.data.sab)** ——要确保视图类型和主进程一致（比如都是Int32Array），且长度对齐（sab.byteLength必须能被元素字节大小整除） - 多个 Worker 共享同一块内存，必须由主进程统一创建并分发；各自
new SharedArrayBuffer()是无效的，彼此内存完全隔离
Atomics.wait() 只在 Worker 里能用，且只等“值不变”
Atomics.wait() 不是 sleep，也不是轮询开关，它是条件挂起：只有当目标位置当前值等于预期值时才阻塞，否则立刻返回 "not-equal"。
- 主线程调用会直接抛
TypeError: wait not allowed on main thread - 视图必须是
Int32Array或BigInt64Array，传Float64Array会报RangeError - 唤醒必须靠另一线程调用
Atomics.notify()，且 notify 前要先Atomics.store()改变该位置的值，否则 wait 永远不会退出 - 典型同步模式：Worker A 等待
Atomics.wait(shared, 0, 0)→ 主线程或 Worker B 执行Atomics.store(shared, 0, 1); Atomics.notify(shared, 0, 1)
无锁 ≠ 无同步逻辑，容易忽略的边界点
真正难的不是写 Atomics.add()，而是设计状态流转协议。比如多个 Worker 同时往一个环形缓冲区写数据，仅靠原子加法不够，还得用 CAS（Atomics.compareExchange()）做预留位，再用 Atomics.store() 提交内容——否则会出现覆盖写或漏写。
-
Atomics.add()、.sub()等只适用于纯数值聚合（计数器、累加和），不适用于结构化数据交换 - 共享内存区域需提前规划好字段布局（比如前 4 字节放计数器，接下来 1020 字节放数据区），所有 Worker 必须严格按约定解读
- 没有 GC 机制，
SharedArrayBuffer生命周期由 JS 引擎自动管理，但一旦所有引用消失，内存就不可恢复——别依赖“稍后还能读”
