链式调用中性能损耗最典型来源是中间数组反复创建；只要连续点号调用且每步返回新数组（如map/filter），就必然产生中间数组，应改用单次遍历、reduce、array.from或生成器优化。
链式调用中性能损耗最典型的来源，就是中间数组的反复创建——它不显眼，但会悄悄吃掉内存、拖慢速度、加重垃圾回收压力。识别它不需要复杂工具，关键看“是否多建了一次数组”；优化也不靠删代码，而在于换思路、换方法。
一眼识别中间数组是否产生
只要写法中出现连续点号调用，且每一步都返回新数组，就一定产生了中间数组：
-
arr.map(x => x * 2).filter(x => x > 10)→ 先建一个等长新数组（map结果），再从中筛选建第二个数组 -
const temp = arr.filter(...); temp.map(...)→ 明确赋值给变量，两次遍历 + 两次内存分配 -
arr.map(x => x.id).length→ 即使只取长度，那个新数组也已完整生成，只是没被后续使用
哪些方法必然生成新数组
这些内置方法每次调用都会分配内存、返回全新数组，链式时无法复用：
- map()：必须分配等长新数组
- filter()：长度不确定，需动态分配
- slice()、concat()、flatMap()：显式拷贝或展开，必然新建
小数组可忽略，大数组要警惕
对几千以内的数组，V8 引擎有较好优化，链式调用完全没问题；但以下场景需特别注意：
- 数组超 10 万项
- Node.js 后端高频处理数据流
- 无意识堆叠：
.map().filter().map().filter()这类长链 - 仅需校验存在性（用
some()）、找首个匹配项（用find()）却写了filter().[0]
真正有效的优化方案
目标是单次遍历、按需计算、避免预分配：
- 手动 for / for...of 循环：在一次循环里完成判断+转换+推入结果，零中间数组
- 用 reduce() 合并逻辑：累加器中只推符合条件的转换后值，跳过中间结构
-
Array.from(arr, callback)：回调中内联条件判断，配合
.filter(Boolean)可比链式少建一个数组 -
生成器函数实现惰性求值：如
function* map(iterable, fn)和function* filter(iterable, pred)，调用时只计算真正需要的元素，适合找前 N 个、提前退出等场景
