sharedarraybuffer 配合 atomics.add 仅支持同进程内多线程原子计数，不适用于跨进程场景；因操作系统内存隔离，需用 redis、数据库事务或主进程聚合等外部方案。
SharedArrayBuffer 配合 Atomics.add 不能用于跨进程计数，只能用于同进程内多线程（如主线程与 Worker、多个 Worker 之间）的共享内存操作。Node.js 的 Worker Threads 和浏览器的 Web Workers 都属于单进程内的多线程模型，它们共享同一 V8 实例和操作系统进程上下文，因此可安全映射同一块 SharedArrayBuffer。
为什么“跨进程”不成立
进程之间有严格内存隔离，操作系统禁止直接共享物理内存页。SharedArrayBuffer 本质是分配一块可被**同进程多个线程并发访问**的底层内存区域，它依赖 V8 的线程调度与内存管理机制，无法穿透进程边界。所谓“跨进程”计数（如多个 Node.js 进程、不同浏览器标签页、不同 Electron 主进程与渲染进程），必须改用外部协调服务：
- Redis 的 INCR 命令（带原子性与网络一致性）
- 数据库的 SELECT FOR UPDATE + UPDATE（需事务支持）
- 专用指标服务（如 Prometheus + Pushgateway 配合幂等上报）
- 主进程中心化分发（在 cluster 模式下由 master 统一接收各 worker 的增量并聚合）
真正可行的场景：单进程内多 Worker 原子计数
这是 SharedArrayBuffer + Atomics.add 的标准用法，适用于高吞吐、低延迟的实时统计，例如页面点击量、API 请求频次、Worker 内部任务完成数：
- 主线程创建 new SharedArrayBuffer(4)，用 new Int32Array(sab) 封装为计数视图
- 通过 worker.postMessage(sab, [sab]) 转移 buffer（transfer list 不可省略）
- 每个 Worker 中重建相同视图：const counter = new Int32Array(msg.data)
- 执行累加统一用 Atomics.add(counter, 0, 1)，不是
counter[0]++或counter[0] += 1 - 读取最终值必须用 Atomics.load(counter, 0)，而非直接访问
counter[0]
环境与安全前提必须满足
否则 SharedArrayBuffer 构造会静默失败或抛出 ReferenceError：
-
浏览器端：服务端响应头需包含
Cross-Origin-Opener-Policy: same-origin和Cross-Origin-Embedder-Policy: require-corp；所有脚本/资源加载加crossorigin属性；不能使用 file:// 协议 -
Node.js 端：启动时加标志
node --experimental-shared-array-buffer server.js；确保版本 ≥ 12.17 且启用 Worker Threads - 运行时可用性检查：
if (typeof SharedArrayBuffer !== 'undefined' && self.crossOriginIsolated)（浏览器）或globalThis.SharedArrayBuffer（Node.js）
常见误用与后果
这些写法看似简洁，但会导致计数严重偏低甚至崩溃：
- 忘记 transfer list → Worker 收到 null，
new Int32Array(null)报错 - Worker 中用
new Int32Array(new SharedArrayBuffer(4))自行创建 → 各自独立内存，无共享效果 - 用
counter[0]++→ 拆成读-改-写三步，多线程下丢失更新（lost update） - 主线程直接读
counter[0]→ 可能读到过期缓存值，必须用Atomics.load() - 在主线程调用
Atomics.wait()→ 抛TypeError: wait not allowed on main thread
