Array.prototype.concat() 不抛出 OutOfMemoryException，但可能因内存耗尽导致崩溃或静默失败；需预判输入规模、监控堆内存使用率（如 performance.memory 或 process.memoryUsage）、验证结果有效性，并优先选用 for 循环、Array.from 或 TypedArray.set() 等低内存开销替代方案。
Array.prototype.concat() 本身不会直接抛出 OutOfMemoryException（那是 .NET 的异常类型），但在 JavaScript 中，它确实可能触发物理内存耗尽导致的进程崩溃或静默失败——尤其当目标是生成一个远超可用 RAM 的巨型数组时。识别这类风险，关键不在于 concat 方法本身，而在于你对输入规模、运行环境和内存行为的预判。
看输入数组的总元素量与单元素内存开销
concat 后的新数组需在堆中分配连续（或逻辑连续）内存空间。若两个数组合计含数千万个基础类型值（如 number、string 引用），或大量对象/大字符串，实际内存占用会远超“元素个数 × 8 字节”的粗略估算：
- 每个 number 在 V8 中通常占 8 字节，但若混入 boxed 对象或长字符串，单个元素可能消耗 KB 级内存
- 字符串底层是 UTF-16 编码，一个长度为 1000 的字符串约占用 2000 字节 + 元数据
- 对象引用本身虽小，但若被 concat 的数组里存的是未释放的 DOM 节点、CanvasImageSource 或 ArrayBuffer，其真实内存归属可能远超 JS 堆报告
查运行时内存上限与当前使用率
浏览器或 Node.js 进程有硬性内存限制：
- Chrome 默认 JS 堆上限约 4GB（32 位更小），Node.js 可通过
--max-old-space-size=8192手动调高，但受物理内存制约 - 使用
performance.memory（仅 Chrome/Firefox）查看usedJSHeapSize与totalJSHeapSize比值；若已 > 85%，concat 大数组极易失败 - Node.js 中可调用
process.memoryUsage()，重点关注heapUsed和heapTotal
验 concat 后是否真正生成了预期数组
不要只依赖无报错就认为成功。以下迹象提示内存已临界或静默降级：
- concat 返回数组的
.length正确，但访问高索引项（如arr[arr.length - 1]）时卡顿数秒或直接崩溃 - 后续调用
JSON.stringify()或arr.forEach()突然中断，控制台无错误，仅页面无响应或进程退出 - DevTools Memory 面板显示“GC频繁”“内存持续上涨后骤降”，说明引擎在强压回收，不可持续
比 concat 与替代方案的内存足迹差异
concat 是“全量复制”：它必须一次性构造完整新数组。相比之下：
- 用
for循环 +push()分批写入目标数组，内存增长平缓，可控暂停 - 使用
Array.from({ length }, (_, i) => ...)按需生成，避免中间大数组 - 对图像/音频等二进制数据，优先用
TypedArray.prototype.set()直接拷贝到预分配缓冲区，绕过通用数组开销
