node --max-old-space-size=4096仅作用于npm run等启动的Node子进程(如vue-cli-service、webpack),与VSCode主界面无关;主进程需用code --max-memory=4096终端启动,Extension Host需通过Developer: Show Running Extensions定位并重启窗口治本。

直接说结论:Node.js 堆栈溢出(JavaScript heap out of memory)不是靠“开启某个跟踪模式”解决的,而是分层处理三个独立进程的内存限制——主进程、Extension Host、Node 子进程。VSCode 本身没有“高级堆栈溢出排查跟踪模式”,但有对应层级的诊断和调参手段。
node --max-old-space-size=4096 是给谁用的?
这个参数只作用于你 npm run 启动的 Node 子进程(比如 vue-cli-service、webpack、ts-node),和 VSCode 主界面完全无关。
- 错误写法:
NODE_OPTIONS=--max-old-space-size=4096放进系统环境变量全局生效 → 可能干扰其他 CLI 工具,且对 GUI 启动的 VSCode 无效(Windows 尤其常见) - 正确做法:在
package.json的 script 字段里显式加前缀,例如:"dev": "node --max-old-space-size=4096 ./node_modules/.bin/ts-node src/index.ts" - Windows 用户必须用
cross-env注入:"dev": "cross-env NODE_OPTIONS=--max-old-space-size=4096 ts-node src/index.ts" - 值不建议盲目拉高:4096 MB(4GB)已足够覆盖绝大多数项目;超过它往往说明代码存在真实泄漏(如未释放的缓存、闭包引用、监听器没
removeListener)
VSCode 主进程卡死或白屏怎么办?
这是 Electron 渲染进程 RSS 内存飙到 3GB+ 导致的 OOM,和你的 Node 项目无关,但症状相似(启动慢、无响应、崩溃日志里带 Out of memory)。
诊断并恢复通过 SSH 隧道连接的 OpenClaw 节点。用于解决配对必需错误、隧道冲突、远程端点错误以及 SSH 目标配置错误等问题。
- 绝对不要双击图标或从 Dock 启动 —— 它无法传递命令行参数
- 必须在终端执行:
code --disable-extensions --disable-gpu --max-memory=4096 . -
--max-memory=4096是 Electron 12+ 才支持的参数,单位是 MB,仅限主进程;--disable-extensions能跳过 ESLint/GitLens 等语言服务预热,省掉 500MB+ 内存 - Mac 用户若外接显示器或用 Intel 核显,
--disable-gpu可减少 200–500MB 渲染内存驻留
Extension Host 占用超 500MB 怎么查?
这不是插件列表里“启用/禁用”能反映的——所有插件共享一个 Extension Host 进程,内存泄漏后不会自动回收,会缓慢爬升并卡在高位。
- 打开命令面板(
Ctrl+Shift+P或Cmd+Shift+P),运行:Developer: Show Running Extensions→ 查看每个扩展的实时内存估算(单位 MB) - 看到某插件显示 >120MB 或
N/A,先禁用它,然后必须关闭当前窗口再重新打开,否则旧进程仍驻留 - 配合
files.watcherExclude治本:"**/node_modules/**"、"**/dist/**"、"**/.turbo/**"(pnpm/turborepo 项目必加) - 别信“全局设置统一排除”——不同仓库结构差异大,
.vscode/settings.json才是唯一可靠位置
为什么 launch.json 里配了 skipFiles 还看不到完整异步调用链?
skipFiles 只控制是否跳过内部文件(如 <node_internals>/**</node_internals>)的断点,和异步堆栈追踪无关。真正影响异步调用链显示的是 Node.js 版本和调试器配置。
- Node.js ≥ v12 才支持
async_hooks,VSCode 默认启用异步堆栈追踪,但前提是启动时没加--no-async-hooks - 确保
launch.json中的type是"node",且request为"launch"或"attach";skipFiles不影响调用栈面板内容 - 如果调用栈里仍缺失 Promise 链,检查是否用了
Promise.allSettled或unhandledrejection未被捕获 → 这类异常会打断异步上下文,调试器无法关联源头 - 想确认异步追踪是否生效?在断点暂停后,展开“调用堆栈”面板,看是否有
async标记的帧;没有的话,大概率是代码里用了setTimeout+setImmediate混合调度,破坏了 async_hooks 链路
真正容易被忽略的点是:这三个内存问题(主进程、Extension Host、Node 子进程)互不干扰,各自有独立的启动参数、配置项和诊断路径。试图用一个开关或一个配置项“一劳永逸”解决所有 heap out of memory,只会反复踩坑。















