最常误用且影响性能的是直接修改原数组的方法：push、pop、shift、unshift、splice，其中shift/unshift时间复杂度为O(n)；filter/map/slice虽安全但链式调用产生多中间数组；大数据量下应避免unshift，改用[item, ...arr]或push+reverse。
哪些数组方法最常被误用却影响性能
直接修改原数组的 push、pop、shift、unshift、splice 在大数据量下容易成为瓶颈，尤其 shift 和 unshift 时间复杂度是 O(n)，因为要重排所有索引。而 filter、map、slice 这类返回新数组的方法虽安全，但频繁链式调用会创建多个中间数组，内存开销明显。
- 处理上万条日志时，避免用
arr.unshift(item)往头部加数据；改用[item, ...arr]或先push再反转（若顺序不敏感） - 连续转换推荐用
reduce合并操作，比如：arr.reduce((acc, item) => { if (item.active) acc.push(item.name.toUpperCase()); return acc;}, []) - 需要“过滤 + 映射”时，
flatMap比filter().map()少一次遍历，且不产生中间数组
find / findIndex / includes 的边界行为必须确认
这三个方法都使用 SameValueZero 比较（即 ===，但 NaN === NaN 返回 true），但对 undefined、null、空槽（sparse array）处理不同。例如稀疏数组 [1, , 3] 中，includes(undefined) 返回 false，因为中间是“空位”，不是 undefined 值。
-
find和findIndex遇到undefined元素会正常匹配；但遇到空槽则跳过，不执行回调 -
includes不识别空槽，只查实际存在的值；若需检测空位，得用arr[i] === undefined && i in arr === false - 对象查找别直接用
includes({a:1})—— 引用比较永远为false，应改用some(item => item.a === 1)
flat / flatMap 处理嵌套结构的实际限制
flat 默认只摊平一层，深层嵌套如 [[[1, 2], [3]], 4] 需显式传参 Infinity，但可能触发栈溢出或无限循环（比如含环引用的对象）。flatMap 本质是 map + flat(1)，适合“每个元素映射为一个数组，再打平”的场景，但无法替代递归扁平化。
- 安全摊平任意深度：用
JSON.stringify+ 正则提取数字/字符串太粗糙，推荐手写递归函数并加深度限制 -
flatMap回调返回非数组值（如字符串、数字）会被自动包装成单元素数组，所以[1,2].flatMap(x => x*2)得到[2,4]，不是[2,4]拼接结果 - 遇到
undefined或null返回值，flatMap会插入空槽，不是跳过 —— 实际表现等价于[].concat(undefined)，结果是[undefined]
for…of vs forEach vs 索引 for 循环怎么选
性能不是唯一标准。现代 V8 对三者优化已很接近，差异更多在控制流和语义：`for…of` 支持 break/continue/return，forEach 回调里 return 只退出当前迭代；纯索引 for 循环最灵活，但易写错边界（如 导致越界）。
立即学习“Java免费学习笔记（深入）”；
- 需要中途退出（如查找首个满足条件项），优先用
for…of或some/find；别用forEach配标志变量 - 要同时访问索引和值，
for…of配entries()比forEach((v,i)更明确：for (const [index, value] of arr.entries()) { /* ... */ } - 遍历
TypedArray（如Uint8Array）时，传统for循环仍略快，且forEach不支持部分类型
很多开发者卡在“该用哪个方法”的纠结里，其实关键不是记全所有 API，而是清楚每个方法的不可逆副作用（比如 sort 会改原数组）、比较逻辑细节（indexOf 用 ===，find 用回调）、以及返回值是否可链式继续操作。真正影响效率的往往不是方法本身，而是没意识到某次 map().filter().map() 走了三趟循环。
