BigUint64Array 不支持 SharedArrayBuffer 是因安全限制：其 BigInt 底层非固定长度、堆分配行为易致竞态，且规范明确排除；须用 Uint8Array + DataView.get/setBigUint64() 模拟，原子操作需拆为32位字段配合 Atomics。
BigUint64Array 本身不支持直接在 SharedArrayBuffer 上构造 —— 这是关键前提。浏览器（包括 Chrome、Firefox、Safari）目前**禁止**将 BigUint64Array 与 SharedArrayBuffer 一起使用，调用 new BigUint64Array(sharedBuf) 会立即抛出 RangeError: invalid buffer type。
为什么 BigUint64Array 不能用于 SharedArrayBuffer？
这是有意为之的安全限制。原因包括：
- JavaScript 的
BigInt和BigUint64Array基于任意精度整数实现，其内部表示不是固定长度的原始二进制块； - 共享内存需保证原子性与跨线程确定性，而 BigInt 的堆分配行为和规范化（如消除前导零）可能引发竞态或非预期的字节布局变化；
- ECMAScript 规范明确将
BigUint64Array和BigInt64Array排除在可共享视图类型之外（仅允许Int8Array、Uint32Array等传统 TypedArray）。
替代方案：用 Uint8Array + 手动字节操作模拟 64 位无符号整数
若需在 SharedArrayBuffer 中安全读写 64 位无符号整数值，标准做法是：
- 用
Uint8Array（唯一被允许用于 SharedArrayBuffer 的整型视图）访问底层字节； - 按小端序（little-endian，JavaScript DataView 默认顺序）手动拼装/拆解 8 字节；
- 配合
DataView提供的getBigUint64()/setBigUint64()方法完成转换。
示例：
const sab = new SharedArrayBuffer(1024); const view = new Uint8Array(sab); // 写入一个 64 位无符号整数（从偏移量 0 开始） const dv = new DataView(sab); dv.setBigUint64(0, 12345678901234567890n, true); // true = little-endian // 读取它 const val = dv.getBigUint64(0, true); // → 12345678901234567890n
注意：DataView 本身不共享，但它的缓冲区（sab）是共享的，因此多个 Worker 可安全地通过各自持有的 DataView 实例并发读写同一段内存（需自行加锁或使用 Atomics 同步）。
若需原子操作，必须绕过 BigUint64Array
SharedArrayBuffer 的原子操作（Atomics）只支持 32 位整数（Uint32Array 等）。对 64 位值做原子读-改-写，只能：
- 拆分为两个 32 位字段（高位 + 低位），用
Atomics.compareExchange配合自旋锁实现 CAS； - 或借助
Atomics.wait()/Atomics.notify()构建用户态互斥锁，再用DataView.setBigUint64()安全更新； - 避免直接对 64 位区域做原子操作 —— 浏览器未提供
Atomics.compareExchange64类 API。
未来可能性
TC39 已有提案（如 proposal-sharedarraybuffer64）探讨为 SharedArrayBuffer 添加原生 64 位原子支持，但尚未进入 Stage 3，短期内不可用。当前所有生产环境都应基于 DataView + SharedArrayBuffer + Uint8Array 组合实现 64 位无符号整数的共享访问。
