TypedArray.prototype.fill() 可高效初始化大缓冲区，支持类型自动转换和范围填充，性能优于手动循环或普通数组方案，推荐作为默认方法。
Array.prototype.fill() 本身不适用于大型内存缓冲区的原始数据初始化，因为它仅作用于普通 JavaScript 数组（即 Array 实例），而无法直接操作 ArrayBuffer、TypedArray（如 Uint8Array、Int32Array）或 DataView 等底层二进制视图。
fill() 对 TypedArray 无效？不，它其实有效但有局限
TypedArray（如 Uint8Array、Float64Array）**继承自 Array.prototype 的部分方法**，其中就包括 fill()。所以你可以直接调用：
const buffer = new ArrayBuffer(1024 * 1024); // 1MB const view = new Uint8Array(buffer); view.fill(0); // ✅ 合法且高效 —— 全部设为 0
但注意：该操作仍受限于 TypedArray 的类型语义和长度范围，且 fill(value, start, end) 中的 value 会按目标类型自动截断或转换（例如对 Uint8Array 填 257 等价于填 1）。
真正适合大缓冲区初始化的原生方法
对于百万级乃至更大规模的原始内存初始化，应优先使用 TypedArray 自带的 fill()（已高度优化），而非转成普通数组再 fill。它在 V8、SpiderMonkey 等引擎中通常被内联为底层 memset 或向量化写入。
- ✅ 推荐：直接对
TypedArray调用.fill(0)或.fill(255) - ✅ 支持起始/结束索引，可只初始化某段区域：
view.fill(0xFF, 1024, 2048) - ❌ 避免：
Array.from({length: n}).fill(0)—— 创建中间数组，内存翻倍且极慢 - ❌ 避免：
new Array(n).fill(0).map(...)—— 完全脱离二进制上下文，无实际缓冲区关联
超大缓冲区（GB 级）的注意事项
即使 fill() 很快，一次性分配 GB 级 ArrayBuffer 仍可能失败（受内存限制与引擎策略影响），且初始化本身需时间。实用建议：
- 分块初始化：用循环 +
subarray()分批调用fill()，降低单次操作压力 - 延迟初始化：仅在首次访问时填充对应页（需封装类管理状态）
- 复用缓冲区：通过
slice()或subarray()复用已有 buffer，避免重复分配 - 考虑
WebAssembly.Memory：若需极致控制，Wasm 内存可调用mem.set()或原生 memset
对比：fill() vs 手动 for 循环 vs 其他方案
在现代引擎中，TypedArray.prototype.fill() 通常比手写 for 循环更快（尤其全量填充），因为引擎可做向量化优化；而 for 循环易受 JIT 限制，且 JS 引擎难以保证其完全消除边界检查。
- ✅
view.fill(0)：简洁、安全、性能最优（推荐默认方案） - ⚠️
for (let i = 0; i ：可读性好，但通常略慢，且易出错（如越界） - ❌
buffer.slice().fill(0)：报错 ——ArrayBuffer无fill方法 - ❌
new DataView(buffer).setUint8(...)：仅设单字节，批量设置需循环，远慢于fill
