array.from() 的 mapfn 参数能降低内存占用，因为它按需计算每个索引的值并直接填入目标数组，仅分配最终结果数组的内存，避免了先创建占位数组再映射的两步开销。
array.from() 的第二个参数（即 mapfn）本身**不优化内存分配**，但它能**避免中间数组的创建**，从而在大数据生成场景中显著减少内存峰值和 gc 压力。
为什么 mapFn 能降低内存占用？
当你写 Array.from({length: 1000000}, (v, i) => i * 2) 时，引擎不会先构造一个含一百万个 undefined 的数组再遍历映射；而是按需计算每个索引对应的值，并直接填入目标数组。整个过程只分配**最终结果数组**的内存，跳过了“占位数组 + 映射后新数组”的两步开销。
对比：Array(1000000).fill().map((_, i) => i * 2) —— 先分配百万项 undefined 数组，再分配百万项结果数组，峰值内存 ≈ 2×结果大小。Array.from({length: 1000000}, (_, i) => i * 2) —— 只分配一次目标数组，峰值内存 ≈ 1×结果大小。
适用场景：纯计算型、无副作用的映射
只有当 mapFn 是纯函数（输入确定、无外部依赖、无修改行为）时，引擎才可能做此优化。以下写法有效：
Array.from({length: N}, (_, i) => i ** 2)Array.from({length: N}, (_, i) => String.fromCharCode(97 + i % 26))-
Array.from({length: N}, (_, i) => ({ id: i, value: Math.random() }))（注意：对象仍会逐个创建，但数组结构本身不冗余）
以下写法**无法规避中间结构或失去优势**：Array.from(arrLike, x => expensiveTransform(x)) —— 若 arrLike 是真实类数组（如 arguments 或 DOM 集合），仍需先读取全部元素，但至少不额外建空数组；Array.from({length: N}, () => Math.random()) —— 每次调用都新建对象/字符串，内存节省体现在数组层面，而非元素内容。
与 for 循环对比：何时选哪个？
如果只需生成简单数值或轻量对象，Array.from + mapFn 语义清晰、代码简洁，V8 等引擎对其有专门优化路径；
若需精细控制（如提前终止、条件跳过、复用对象实例），for 更灵活：
- 需要复用同一对象引用？→ 用
for手动 push 同一对象，避免mapFn每次返回新对象 - 生成过程中可能中断？→
for可加break；Array.from是全量同步执行 - 元素构造成本极高且可缓存？→
for可结合闭包或外部缓存，mapFn难以共享状态
小技巧：配合 Array.prototype.constructor 控制类型
默认生成普通数组，但你可以指定构造器来生成 Uint32Array 等类型化数组，进一步压缩内存：
Array.from({length: 1000000}, (_, i) => i * 2, Uint32Array)
这行代码直接生成 Uint32Array，每个元素占 4 字节（而非普通数组中 Number 占 8 字节 + 对象头等），整体内存可减少 50% 以上，且无额外拷贝。
