sharedarraybuffer + atomics 能加速图像处理，但必须严格对齐像素格式、分块同步（如64×64）、用atomics.compareexchange避免条件竞态，并确保coop/coep跨域隔离。
SharedArrayBuffer + Atomics 能显著加速图像处理，但直接套用会出错——关键不在“能不能并行”，而在“怎么避免像素级竞态”和“如何让线程不空等”。
SharedArrayBuffer 创建时字节对齐必须匹配图像数据类型
图像像素通常按 RGBA（4 字节/像素）或灰度（1 字节/像素）排列，而 SharedArrayBuffer 本身不关心语义，只管字节长度。如果视图类型和实际数据宽度错位，Int32Array 读取会跨像素越界，结果不可预测。
- RGBA 图像：用
Uint8Array视图，缓冲区大小 = 宽 × 高 × 4；别用Int32Array直接映射，除非你明确按 32 位整数打包（如每个 int 存一个像素） - 灰度图：用
Uint8Array最安全；若想用Int32Array加速批量计算（比如每 4 像素一组做 SIMD 式运算），需确保起始地址 % 4 === 0，否则Atomics操作可能被浏览器拒绝（部分引擎对非对齐访问抛RangeError） - 创建后立即检查：
sharedBuffer.byteLength是否等于预期总字节数，且new Uint8Array(sharedBuffer).length匹配图像尺寸
Atomics.wait() 不适合逐像素同步，要用分块 + CAS 标志位
有人想让每个 Worker 处理一行后发信号，用 Atomics.wait(view, rowIdx, 0) 等待主线程唤醒——这在高分辨率图像下极易触发大量阻塞，线程池迅速卡死。真实场景里，等待粒度必须粗于单像素，且不能依赖轮询。
- 把图像切成 N 个矩形块（比如 64×64），每个 Worker 处理一块；用一个
Int32Array标志位数组记录完成状态：doneFlags[i] = 1表示第 i 块完成 - Worker 结束时调用
Atomics.or(doneFlags, i, 1)置位，主线程用Atomics.load(doneFlags, i)轮询（低频，仅检查进度） - 千万别对每个像素做
Atomics.wait()——它设计用于“长时间等待事件”，不是高频同步；频繁调用会导致主线程被挂起，UI 冻结
图像算子中避免拆解原子操作，尤其条件写入
比如实现“阈值二值化”：若像素值 > 128，则设为 255，否则设为 0。错误写法是 if (Atomics.load(pixels, idx) > 128) Atomics.store(pixels, idx, 255) ——中间存在竞态窗口，其他线程可能在 if 和 store 之间修改该位置。
- 正确做法：用
Atomics.compareExchange(pixels, idx, oldValue, newValue)循环重试，直到成功 - 更高效方案：把逻辑移到 Worker 内部完成计算，只用原子操作写最终结果。例如先在本地
Uint8Array缓冲区算完一整块，再用Atomics.store()或批量Uint8Array.set()（注意：后者非原子，需确保无并发写同一区域） - 涉及多通道联动（如 RGB 转灰度）时，必须保证三通道地址连续且用同一视图操作，否则
Atomics无法保障跨字节原子性
跨域隔离头缺失会导致 SharedArrayBuffer 初始化静默失败
Chrome/Firefox 在 2022 年后强制要求 COOP/COEP，否则 new SharedArrayBuffer(1) 返回 null 或抛 TypeError，但控制台可能不报错——图像处理代码一路执行到 new Int32Array(null) 才崩，堆栈难定位。
- 检查响应头是否含：
Cross-Origin-Opener-Policy: same-origin和Cross-Origin-Embedder-Policy: require-corp - 本地开发用
http-server -p 8080 --cors --coep --coop（需支持参数的服务器）；Webpack/Vite 代理无法注入这些头，必须由后端或静态服务器设置 - 在代码开头加防护：
if (!self.SharedArrayBuffer) throw new Error('SharedArrayBuffer not available — check COOP/COEP headers');
最易被忽略的是：SharedArrayBuffer 的内存生命周期完全独立于 JS 对象引用，一旦所有视图被 GC，缓冲区就失效，但 Worker 里可能还在读——没有运行时警告，只有静默乱码。务必用 postMessage 显式通知 Worker 缓冲区已弃用，或统一用弱引用管理视图存活期。
