ArrayBuffer 长度必须固定，因其本质是映射操作系统内存块的连续原始引用，不可重解释以保障视图边界安全、引擎深度优化及跨线程/语言边界的内存隔离，在高性能IO中提供确定性性能边界。
ArrayBuffer 的长度在创建后不可更改，这不是限制，而是设计选择——它让底层内存布局保持确定性，从而支撑高性能 IO 场景下的安全、高效数据流转。
为什么 ArrayBuffer 长度必须固定？
ArrayBuffer 本质是**一段连续的原始内存引用**，其 byteLength 属性直接映射到操作系统分配的物理或虚拟内存块大小。一旦创建，JS 引擎就将其视为“不可重解释”的内存切片：不支持 push/pop/resize 等动态操作，避免触发内存重分配与数据拷贝视图（如 Uint8Array、DataView）依赖该长度做边界检查和偏移计算，变动长度会导致所有关联视图失效或行为未定义引擎可据此做深度优化：例如在 WebAssembly 或 WebGL 中，直接将 ArrayBuffer 底层指针传递给 C/C++ 模块，无需中间转换不可变长度如何实现内存隔离？
在跨线程（如 Worker）、跨上下文（如 iframe）或跨语言边界（如 ArkTS 与 Native）传输时，ArrayBuffer 的固定结构成为内存安全的基石：转移（transfer）模式下，ArrayBuffer 的 Native 内存块被“移交”给目标线程，原 JS 对象壳自动 detached，杜绝双线程同时写同一块内存的风险拷贝模式虽复制内存，但因长度固定，引擎可使用零拷贝路径（如 memcpy 或 DMA 直接页映射），避免逐字节解析配合 structuredClone() 或 postMessage({ buffer }, [buffer]) 时，引擎明确知道要搬运多少字节，无需运行时探测或序列化开销在高性能 IO 中的实际价值当处理图像解码、音频流、网络协议包或大型二进制文件时，固定长度 ArrayBuffer 提供了可预测的性能边界：读取文件 chunk 时，用new ArrayBuffer(64 * 1024)预分配 64KB 缓冲区，后续每次 read() 直接填入，无 GC 压力WebSocket 接收二进制帧，服务端按协议头声明 payload 长度，前端用对应大小 ArrayBuffer + DataView 解析，跳过 JSON.parse 的语法树构建成本WebGL 纹理上传前，将像素数据写入预分配的 Uint8Array 视图，GPU 驱动可直接锁定该内存段进行 DMA 传输它不是为灵活而生，而是为确定性而建——长度不变，意味着内存位置可信、传输代价可知、并发访问可控。