sharedarraybuffer 无法直接同步 dom 对象，只能通过共享轻量元数据（如 id、坐标、状态标志等）实现高速同步；主线程与 worker 各自维护 dom 映射，借助定长结构体、原子操作和双缓冲协议协作，避免序列化开销，延迟可达亚毫秒级。
SharedArrayBuffer 本身不能直接同步 DOM 描述符，因为它只支持原始二进制数据（如 Int32Array、Float64Array），而 DOM 对象（如 Element、Node）是不可序列化、不可共享的 JavaScript 对象，无法写入 SharedArrayBuffer。所谓“原始 DOM 描述符”的高速同步，实际是指：用结构化、轻量、可共享的数据格式（如 ID、坐标、可见性、类型标记等）代替真实 DOM 节点，在主线程与 Worker 间低延迟交换状态，并由各自线程按需映射或更新真实 DOM。
核心思路：用可共享元数据替代 DOM 对象
DOM 不可跨线程共享，但描述 DOM 状态的“元数据”可以。例如：
- 一个按钮可能只需同步：
id: "submit-btn"、visible: true、disabled: false、text: "提交"、rect: {x: 120, y: 80, w: 100, h: 36} - 这些字段全可转为整数或固定长度字符串（如用 UTF-8 编码存入 SharedArrayBuffer 的 Uint8Array 段）
- 主线程负责读取真实 DOM、提取元数据并写入共享内存；Worker 负责读取元数据、执行计算（如碰撞检测、布局分析）、写回结果；主线程再依据结果批量更新 DOM
内存布局设计：定长结构体 + 偏移寻址
SharedArrayBuffer 需预分配固定大小，推荐按结构体对齐方式组织。例如定义每个 DOM 描述符占 64 字节：
- bytes 0–3：type（uint32，0=div, 1=button, 2=input…）
- bytes 4–7：id_hash（uint32，FNV-1a 哈希，避免存字符串）
- bytes 8–11：x, 12–15：y, 16–19：width, 20–23：height（全部 int32，单位 px）
- bytes 24–27：flags（bitmask：bit0=visible, bit1=disabled, bit2=dirty…）
- bytes 28–63：预留或用于短文本哈希/索引（如 text_id 查表）
Worker 和主线程使用相同 TypedArray 视图（如 new Int32Array(sharedBuf, offset, 16)）访问同一块区域，无需序列化/反序列化开销。
同步协议：原子操作 + 版本号 + 双缓冲
避免竞态的关键不是锁，而是无锁协作模式：
- 在共享内存起始位置预留 2 个 Int32：一个作为 write_version（主线程递增），一个作为 read_version（Worker 递增）
- 主线程写完一批描述符后，执行
Atomics.add(view, 0, 1)更新 write_version - Worker 每次循环检查
Atomics.load(view, 0) !== lastRead，若变化则批量读取，处理后调用Atomics.add(view, 1, 1)标记已读 - 为防覆盖，可用双缓冲区：两组描述符区域 + 一个 buffer_index（0 或 1），通过原子切换指针
主线程与 Worker 协作示例（简化）
主线程中：
- 监听 DOM 变化（MutationObserver 或 requestIdleCallback 批量采集）
- 将变更节点映射为结构体，写入当前活动 buffer 区域
- 原子更新 write_version，触发 Worker 检查
- 定期读取 Worker 写回的结果区（如计算后的 focusTargetId、scrollSuggestion），批量 patch DOM
Worker 中：
- 轮询 write_version，发现更新即读取描述符数组
- 执行纯计算逻辑（无 DOM API、无 this、无闭包）：比如根据所有按钮 rect 判断哪个最靠近鼠标轨迹
- 将结果（如 target_id、score、timestamp）写入结果区，原子更新 read_version
整个过程不涉及 JSON.stringify、postMessage 序列化，延迟可压至亚毫秒级（实测典型更新耗时
本质上，SharedArrayBuffer 同步的不是 DOM，而是 DOM 的“数字孪生”——一套精简、确定、可预测的状态快照。它要求你放弃直接操作对象的直觉，转而设计可计算、可验证、可版本化的描述协议。不复杂但容易忽略。
