array.from({ length: n }, () => ({})) 是初始化含独立对象数组的标准解法，fill() 因只复制引用会导致修改一个影响全部，而 new array(n).map() 会因稀疏数组返回 undefined。
fill 不能直接生成不同对象，这是最常踩的坑
Array.prototype.fill() 会把同一个引用复制到每个位置。如果你用 fill({}) 或 fill(new Date())，得到的是一个装着多个相同对象引用的数组——改一个，全跟着变。
常见错误现象：const arr = new Array(3).fill({}); arr[0].x = 1; console.log(arr); 输出三个 {x: 1}，不是你想要的“各自独立”。
- 使用场景：需要初始化长度固定、但每个元素是独立对象（如空
{}、[]、自定义实例）的数组 - 根本原因：
fill不执行构造逻辑，只做浅拷贝引用 - 性能影响：看似快，实则埋下隐性 bug，后期排查成本远高于初始化那点开销
map 是正确路径，但得配合 Array.from
想让每个位置调用一次构造逻辑，得用 Array.from() ——它接受一个类数组长度和一个映射函数，天然支持“为每个索引生成新值”。map 本身不能凭空造数组，必须有个可遍历的源。
正确写法：Array.from({ length: 3 }, () => ({}))，而不是 new Array(3).map(() => ({}))（后者返回全是 undefined，因为 new Array(3) 创建的是稀疏数组，没有可枚举属性）。
-
Array.from({ length: n }, fn)是标准解法，fn每次都重新执行 - 参数差异：
fn接收两个参数：(_, index)，第一个是undefined（因源对象无值），第二个是当前索引，可用于生成带序号的对象 - 兼容性：ES6+，现代环境无压力；若需兼容老环境，可用
Array(n).join().split(',').map(() => ({}))，但不推荐——语义差且有边界问题
需要带索引或动态数据时，别硬套 fill + map 组合
有人试图写 new Array(3).fill(null).map((_, i) => ({ id: i }))，虽然能跑通，但多了一次无意义的 fill(null)，还容易让人误以为 fill 在起作用。
这写法本质还是靠 map 做事，fill 只是“填坑”用的临时占位——不如直给 Array.from 干净。
- 错误信号：看到
fill(null)或fill(undefined)配合map，基本说明作者没意识到Array.from的存在 - 如果真要用
map，确保源数组已“具象化”，比如Array.from({ length: 3 }).map((_, i) => ...) - 性能上差别微乎其微，但可读性和意图表达差一截
复杂对象初始化要防深引用陷阱
哪怕用了 Array.from，如果构造函数返回的是含嵌套对象的结构（比如 { user: { name: '' } }），仍要注意是否意外共享了内层引用。
示例：Array.from({ length: 2 }, () => ({ config: { timeout: 5000 } })) —— 这里每个 config 是独立对象，没问题；但若写成 const base = { timeout: 5000 }; Array.from({ length: 2 }, () => ({ config: base }))，就又掉进引用坑了。
- 关键判断：每次回调中是否都执行了对象字面量或
new表达式 - 建议对深层结构用展开语法或
structuredClone（需环境支持），避免手写深拷贝逻辑 - 容易被忽略的地方：测试时只改顶层字段看不出问题，一旦修改嵌套属性（如
arr[0].config.timeout = 1000），才发现arr[1]也变了
