内存屏障在 Web Workers 中虽不直接暴露，却是保障主线程与 Worker 间数据可见性的底层机制；它通过 CPU 缓存同步、postMessage 隐式屏障及 Transferable 的 release/acquire 语义起作用，带来真实同步开销。
内存屏障在 Web Workers 中不直接暴露、也不由开发者手动插入，但它在底层真实存在并默默起作用——理解它，关键不是“怎么用”，而是“为什么 Worker 通信看似简单，却仍有同步成本”。
内存屏障是浏览器和 CPU 协同保障可见性的机制
Worker 与主线程运行在不同线程（甚至不同 CPU 核心），各自有独立的寄存器和缓存。当你在主线程修改一个 ArrayBuffer 数据后发给 Worker，Worker 读到的值是否最新？这不取决于 JS 代码本身，而依赖底层硬件与运行时的内存一致性保障：
- CPU 缓存不会自动同步：写操作可能暂存在写缓冲区（store buffer），未立即刷入主存；读操作可能命中过期缓存行
- JS 引擎（如 V8）在关键位置插入隐式内存屏障：比如 postMessage 传输 Transferable 对象时，会触发 StoreLoad 全屏障，强制刷新写缓冲区、清空失效队列，确保数据对目标线程可见
- volatile 语义在 JS 中没有直接对应，但 Transferable 的所有权移交机制天然具备发布（release）+ 获取（acquire）语义，等效于加了配套的写/读屏障
同步开销主要来自屏障引发的缓存刷新与序列化协同
内存屏障本身不是“耗时操作”，但它会触发一系列代价可观的硬件行为：
- 执行 StoreLoad 屏障时，CPU 需等待所有待写数据落盘，并处理所有缓存一致性协议（如 MESI）消息，可能造成数十纳秒到微秒级停顿
- 当使用结构化克隆（非 Transferable）传输对象时，序列化/反序列化过程虽不直调屏障，但引擎会在拷贝前后插入屏障，防止编译器或 CPU 重排导致读到中间态
- 频繁的小数据 postMessage（如每毫秒发一次状态）会不断触发屏障，累积成可观延迟；而单次大块 Transferable 传输只触发一次屏障，效率更高
你实际能控制的“屏障相关优化”只有三点
开发者无法写 __asm mfence，但可通过 API 使用模式间接影响屏障行为：
- 优先用 Transferable Objects：传 ArrayBuffer、MessagePort 等可转移对象，避免拷贝，也减少屏障触发频次
- 合并通信批次：把多次小更新攒成一个对象再 postMessage，比连续发 10 次更省屏障开销
- 避免在 Worker 内部高频轮询共享状态：JS 没有真正的共享内存（SharedArrayBuffer 在多数环境受限），轮询本质是反复读本地副本，无法绕过屏障逻辑，纯属浪费
本质上，Web Workers 的“轻量多线程”优势建立在隔离之上，而隔离与可见性之间，内存屏障就是那个沉默的守门人——看不见，但删不掉；不显式写，却处处生效。
