v8 的大对象空间没有独立配置参数，其内存上限由 `--max-old-space-size` 统一控制；它属于老生代的一部分，不单独设限。实际进程内存占用远超堆限制，主要源于 buffer 等堆外分配，v8 堆参数对此无约束力。
在 V8 引擎中，内存被划分为多个逻辑空间：新生代（Young Generation）、老生代（Old Generation）以及专门用于存放大对象的 Large Object Space（LOS）。值得注意的是，Large Object Space 并非一个完全独立的内存区域——它在逻辑上归属于老生代，不拥有专属的大小限制或配置选项。这意味着你无法通过类似 --max-large-object-space-size 的 flag 来单独调整它；它的容量上限完全由 --max-old-space-size 决定。
V8 将超过 128 KB 的单个对象（如大型数组、字符串或 ArrayBuffer）直接分配到 Large Object Space，以避免在常规老生代中造成碎片化。因此，当大量分配 ≥128 KB 的对象时，这些对象会迅速消耗 --max-old-space-size 所设定的老生代总限额。
以下是一个可复现的验证示例：
node --max-old-space-size=100 --trace-gc -e \
"var a = []; \
for (let i = 0; i < 120; i++) { \
console.log(i); \
a.push(new Array(1 << 17)); \ # 每个数组约 1 MB（131,072 字节）
}"该脚本将尝试分配约 120 个 1 MB 数组。由于 --max-old-space-size=100（单位为 MB），V8 实际仅能容纳约 95–98 个此类对象后触发 GC 失败或 OOM —— 这正是 Large Object Space 受限于老生代总配额的直接体现。
⚠️ 需特别注意：进程整体内存使用量（如 top 中显示的 RES）可能远超 --max-old-space-size 设置值。原因在于 Node.js 中大量使用 堆外内存（off-heap memory），例如：
- Buffer 实例（底层基于 C++ malloc，不经过 V8 堆管理）
- TypedArray 的底层 ArrayBuffer（若未绑定 JS 对象，可能脱离 GC 跟踪）
- 原生模块（如数据库驱动、图像处理库）的内部内存分配
这些分配完全绕过 V8 的垃圾回收器和所有 --max-* 参数，因此 --max-old-space-size 对它们毫无约束力。这也是为何你的测试进程能飙升至 10 GB+ 内存却未触发 V8 OOM 的根本原因。
✅ 总结建议：
- 若需限制大对象堆内存，请调高 --max-old-space-size，但需权衡 GC 停顿时间；
- 若目标是控制总内存（含堆外），应结合操作系统级手段（如 ulimit -v 或容器内存限制）及 Node.js 层监控（如 process.memoryUsage() + Buffer.poolSize 调优）；
- 避免无意中长期持有大 Buffer 引用，防止堆外内存泄漏；
- 使用 --trace-gc --trace-gc-verbose 辅助诊断内存分配行为。
理解 Large Object Space 的“依附性”与堆外内存的“自治性”，是高效调优 Node.js 内存的关键前提。
