Atomics是JavaScript标准的多线程原子操作API，非HTML功能；必须与SharedArrayBuffer配合在Web Worker中使用，且需满足跨域隔离（COEP/COOP响应头）、crossorigin属性及HTTPS/localhost协议三条件，否则报错。
HTML 中没有 Atomics 对象 —— 它是 JavaScript（ECMAScript）标准的一部分，不是 HTML 的功能。你在浏览器里能用 Atomics，靠的是 JS 引擎（如 V8、SpiderMonkey）实现，且必须配合 SharedArrayBuffer 使用；但它的可用性受跨域策略和安全上下文严格限制，不是“写个 HTML 就能用”。
为什么在浏览器里直接 new SharedArrayBuffer() 会报错？
现代浏览器默认禁用 SharedArrayBuffer，防止 Spectre 类漏洞利用。未启用跨域隔离（Cross-Origin Isolation）时调用会抛出：SharedArrayBuffer is not enabled in this context。
- 必须在
https://协议下运行（http://localhost是例外） - 响应头需包含：
Cross-Origin-Embedder-Policy: require-corp和Cross-Origin-Opener-Policy: same-origin - 若通过 iframe 加载，子页面也需声明相同策略，否则
postMessage传SharedArrayBuffer会失败
Atomics.wait() 和 Atomics.notify() 配合使用时为何常“不唤醒”？
Atomics.wait() 只对 Int32Array 或 BigInt64Array 有效，且要求目标位置当前值等于传入的 expectedValue 才挂起；Atomics.notify() 唤醒的是正在该位置等待的线程 —— 二者必须作用于同一 SharedArrayBuffer 的同一偏移地址，且数组视图类型一致。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 错误示例：
const sab = new SharedArrayBuffer(1024); const i32 = new Int32Array(sab); const f64 = new Float64Array(sab);→Atomics.wait(f64, 0, 0)会直接抛TypeError: invalid typed array type -
Atomics.wait()在非主线程中才真正挂起（主线程调用会立即返回"timed-out"） -
Atomics.notify()返回实际唤醒的等待线程数，为0很可能是因为没人真在等（比如线程还没执行到wait，或用了不同视图/索引）
常见原子操作：compareExchange vs add vs load/store 的行为差异
Atomics.compareExchange() 是最常用的同步原语，用于实现自旋锁或无锁栈；Atomics.add() 适合计数器；Atomics.load()/Atomics.store() 是带内存顺序保证的读写，不能替代普通赋值。
立即学习“前端免费学习笔记（深入）”；
-
Atomics.compareExchange(i32, 0, 0, 1)：仅当i32[0] === 0时设为1，返回旧值（0表示抢锁成功） -
Atomics.add(i32, 0, 1)：原子加 1，返回加之前的值（可用于实现 ticket lock） -
i32[0] = 1是非原子写，多线程下可能被覆盖；必须用Atomics.store(i32, 0, 1) - 所有
Atomics.*操作默认使用"seqcst"内存序，无需手动指定，但性能略低于"relaxed"（目前浏览器暂不支持显式指定）
真正麻烦的不是语法，而是跨线程状态同步的时机判断 —— 比如一个 Worker 正在 wait，但主线程误以为它已就绪而提前 notify，就会漏唤醒。这类问题无法靠单次 console.log 复现，得靠 Atomics.notify() 的返回值 + 显式轮询 + 超时控制来兜底。
