栈溢出不触发垃圾回收，因其属于栈空间耗尽的硬性错误，与堆内存管理的gc机制完全独立；栈帧销毁自动即时，无需gc参与，而深层递归中创建的堆对象仅在后续堆gc中可能被回收。
同步调用栈溢出（RangeError: Maximum call stack size exceeded）本身不触发垃圾回收，V8 也不会在栈溢出发生时“主动回收内存”来缓解问题。它本质是栈空间耗尽的硬性错误，和垃圾回收机制属于两个独立的内存管理层面。
栈溢出是栈空间分配失败，不是堆内存问题
调用栈由操作系统或运行时划出固定大小的连续内存区域（通常几MB），用于存放函数调用帧（参数、局部变量、返回地址）。每次函数调用都会在栈顶压入一个新帧；返回则弹出。这个过程完全在栈上进行，不涉及堆分配，也不依赖 GC。
当递归过深或意外死循环调用导致栈帧数量超过上限，V8 就直接抛错并终止执行——此时连进入 GC 流程的机会都没有，因为 GC 主要工作在堆（Heap）上，而栈溢出发生在栈（Stack）上。
栈帧销毁是自动且即时的，无需 GC 参与
只要函数正常返回，其栈帧就立即被 ESP 指针下移清除，里面的局部变量（包括基本类型值和对象引用）也随之失效。这种销毁是机械的、确定性的，不走标记清除或任何 GC 算法：
- 基本类型（如
let n = 100）值直接从栈中消失 - 引用类型（如
let obj = {x: 1}）的引用地址从栈中消失，若该对象在堆中再无其他引用，才可能在后续某次堆 GC 中被回收
真正影响 GC 的，是栈溢出前可能遗留的堆引用
虽然栈溢出本身不触发 GC，但它可能暴露出潜在的内存隐患。例如：
- 深层递归中持续创建闭包或大对象（如
arr.push(new Array(10000))），这些对象存在堆中，而栈帧里只存着对它们的引用 - 一旦栈崩溃，这些堆对象若仍被全局变量、定时器、事件监听器等意外持有，就变成“不可达但未释放”的悬挂状态，等待下次 GC 清理
- 但注意：这不是栈溢出“导致”了内存泄漏，而是代码逻辑同时引发了栈溢出和堆引用失控
调试时看到的 GC 日志，和栈溢出无关
如果你在 Node.js 启动时加了 --trace-gc，并在栈溢出前看到 GC 输出，那只是巧合——GC 是按堆内存压力、对象晋升频率等条件自主触发的，和当前是否即将栈溢出毫无关系。V8 不会因为检测到“栈快满了”就提前跑一次 GC 来腾地方。
