SharedArrayBuffer 是唯一支持多 Worker 共享内存的机制，但需跨域隔离、transfer 传递、Atomics 同步，否则必现竞态或损坏。
SharedArrayBuffer 是唯一能让多个 Worker 真正共享同一块内存地址的机制，但默认被禁用，且必须配合 Atomics 才能安全读写——不加同步直接读写必然出现竞态或静默数据损坏。
为什么 new SharedArrayBuffer() 会报错：跨域隔离缺失
现代浏览器强制要求跨域隔离（Cross-Origin Isolation）才能启用 SharedArrayBuffer，否则构造函数抛出 TypeError: SharedArrayBuffer is not enabled。这不是配置问题，而是安全策略硬限制。
- 必须在主页面响应头中同时设置：
Cross-Origin-Embedder-Policy: require-corp和Cross-Origin-Opener-Policy: same-origin - 静态资源（如 Worker 脚本）也需同源或显式声明
crossorigin属性，否则加载失败 - 本地
file://协议完全不可用，必须走http://或https://（推荐用npx serve或 VS Code Live Server）
Worker 间传递 SAB 的正确方式：postMessage + transferable
不能把 SharedArrayBuffer 当普通对象序列化传递，必须通过 postMessage() 的 transfer 机制移交所有权——否则接收端拿到的是空 buffer，且原 Worker 失去访问权。
- 发送方：
worker.postMessage({ buffer: sab }, [sab]);—— 第二个参数是 transfer list，sab必须显式列出 - 接收方：
onmessage = ({ data }) => { const sab = data.buffer; }，此时sab可直接用于Int32Array等视图 - 切记：transfer 后原线程无法再访问该
SharedArrayBuffer，若需多 Worker 共享，主页面应生成后分别 transfer 给每个 Worker
不用 Atomics 就等于裸奔：典型竞态场景与修复
即使有了 SharedArrayBuffer，直接对 Int32Array 索引赋值（如 view[0] = 42）在多线程下不保证原子性，尤其在不同 CPU 核心上运行时，可能读到撕裂值（torn read）或丢失更新。
- 写入必须用
Atomics.store(view, index, value)，读取优先用Atomics.load(view, index) - 需要条件等待时（如一个 Worker 等待另一个填完数据），用
Atomics.wait(view, index, expectedValue)+Atomics.notify(view, index, count) - 避免用
++view[i]这类复合操作，它等价于读-改-写三步，必须拆成Atomics.add(view, i, 1) - 注意：Chrome 120+ 已废弃
Atomics.wait()在非SharedArrayBuffer视图上的使用，务必确认视图绑定的是 SAB
大缓冲区初始化与内存布局设计建议
初始化百 MB 级 SharedArrayBuffer 很快，但后续按需填充、分片管理比一次性全写更可控；结构设计直接影响缓存行竞争和 Atomics 开销。
- 避免所有 Worker 频繁读写同一缓存行（64 字节），可预留 padding：例如每 4 个
Int32Array元素后插入 12 字节空隙，防止 false sharing - 用
new Uint8Array(sab)做底层搬运，再用new Float32Array(sab, offset, length)构建逻辑视图，避免重复分配 - 不建议用
ArrayBuffer.slice()分割 SAB——它返回普通 ArrayBuffer，失去共享能力；应统一用偏移量 + 长度构造视图 - Worker 退出前无需手动释放 SAB，但长期运行时若反复创建大 SAB，需注意内存未及时回收（V8 目前无即时 GC 回收 SAB）
真正麻烦的从来不是怎么创建 SAB，而是确定哪些字段需要原子操作、哪些区域可以无锁只读、以及如何让 notify/wait 的等待逻辑不卡死——这些必须结合具体数据流来设计，没法套模板。
