array.prototype.concat() 不直接导致内存溢出，但在大数组合并时因需分配连续内存而放大loh碎片化风险；其危险性源于后续操作（如flat、json.stringify）触发隐式深拷贝或临时对象分配。
array.prototype.concat() 本身不会直接触发物理内存溢出（如 outofmemoryexception），但它在特定组合条件下会成为内存压力的“放大器”——尤其当输入数组本身已占用大量连续堆内存，且合并后需分配新空间时。识别风险的关键不在于 concat() 是否“安全”，而在于它暴露了底层内存分配的真实瓶颈。
看原始数组是否已逼近大对象堆（LOH）阈值
JavaScript 引擎（如 V8）对大数组有隐式分代管理：单个数组若元素总字节数 ≥ 85,000 字节（约 10KB+ 的 float64 数组或数万字符串），很可能被分配到大对象堆（LOH）。LOH 不频繁回收，且易碎片化。concat() 创建新数组时必须分配一块**新的、足够容纳全部元素的连续内存块**——若原数组已占满 LOH 碎片间隙，即使总空闲内存充足，也会因无法找到连续空间而失败。
- 检查方式：估算
array.length × 每元素字节数。例如new Float64Array(100000)占用 800KB；Array(200000).fill('hello')中每个字符串引用约 8 字节（64 位），仅引用就达 1.6MB，加上字符串内容更甚。 - 预警信号：调用 concat() 后进程 RSS 内存陡增、GC 频率异常升高、后续大数组分配开始失败。
观察 concat() 返回数组是否引发隐式深拷贝链
concat() 虽不递归展开嵌套，但若数组含 TypedArray、ArrayBuffer 视图或大型对象引用，其浅拷贝行为会复制引用而非数据。真正危险的是后续操作——比如立即对 concat 结果调用 flat()、map() 或传给 JSON.stringify()。这些操作可能触发：
- TypedArray 合并后调用
.buffer.slice()→ 复制底层 ArrayBuffer → 内存翻倍 - 含大量短字符串的数组被 JSON 序列化 → 临时构建巨型字符串 → 触发 LOH 分配
- 结果数组被长期持有（如赋值给全局变量或闭包），阻碍 GC 回收原始数组
验证引擎是否在后台执行不可见的中间分配
V8 等引擎对 concat() 有优化（如“copy-on-write”式延迟分配），但该优化仅适用于简单原始值数组。一旦涉及以下情况，引擎会退回到朴素实现：
- 数组含 accessor 属性、Proxy、稀疏索引（
arr[0]=1; arr[1000000]=2）→ 必须遍历全部 length 索引，分配完整新数组 - 跨 realm 数组（如 iframe 中创建的数组）→ 无法共享优化路径，强制深拷贝
- 使用
concat(...arrays)展开超多数组（如 1000+ 个中等大小数组）→ 引擎内部参数处理开销叠加，增加栈与堆压力
用轻量级探测代替全量 concat
上线前可用低开销方式预判风险：
- 测长度与类型：
if (arr1.length + arr2.length > 1e6 && arr1.every(Number.isFinite) && arr2.every(Number.isFinite))→ 提示可能需分批 - 查内存水位（仅 Node.js）：
process.memoryUsage().heapTotal / 1024 / 1024> 1200 MB 时慎用 concat 大数组 - 用
new Array(len).length === len快速排除稀疏数组（稀疏数组 concat 性能差且内存不可预测）
