vscode调试时内存持续上涨主因是断点暂停阻止gc且调试器强制保留大对象引用链；应手动置空大变量、用条件断点、禁用自动展开、限制对象展开深度，并通过process explorer杀extension host进程释放内存。
调试时大对象不释放，debugger 断点卡住后内存持续上涨
VSCode 调试器（尤其是 Node.js 或 Python）在断点暂停时，会强制保留当前作用域所有变量的完整引用链，包括闭包、this 上下文、模块缓存甚至未被显式使用的临时对象。一旦你调试的是含大量嵌套结构、二进制 buffer、或循环引用的对象（比如一个解析了 10MB JSON 的 data 变量），V8 或 Python 解释器的堆快照就会膨胀，且暂停期间 GC 不触发——这不是泄漏，是设计使然。
实操建议：
- 在断点前手动删掉不需要 inspect 的大变量：
data = null或delete globalThis.bigBuffer，再继续单步 - 避免在
for循环体里设断点；改用条件断点：if (i % 1000 === 0) debugger，减少堆驻留频次 - Node.js 调试时，在
launch.json中加"runtimeArgs": ["--max-old-space-size=4096"]，仅限子进程有效（和主进程的--max-memory不冲突） - Python 调试不要依赖
pylance实时类型推导：在.vscode/settings.json里关掉"python.analysis.autoSearchPaths": false，否则每次step into都可能触发全路径扫描
Debug: Toggle Breakpoint 后堆栈溢出 panic 的真实原因
这不是 JS/Python 代码的栈溢出，而是 VSCode 自身调试适配层（vscode-js-debug 或 debugpy）在处理深度嵌套对象展开时，递归序列化失败导致的 native panic。典型现象是：点击变量旁的三角箭头展开 obj.items[0].children[0].meta，UI 卡死几秒后整个调试会话崩溃，终端报 FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory。
关键区别在于——这个错误发生在 VSCode 主进程的渲染线程，不是你的目标程序。
实操建议：
- 禁用自动展开：在
settings.json加"debug.inlineValues": false，彻底关闭行内变量提示 - 限制调试器对象展开深度：对 Node.js，加
"debug.javascript.maxNodeModuleSize": 5000（单位 KB）；对 Python，设"python.debugging.showGlobalVariables": false - 绝对不要在调试时右键“Copy Value”一个含
Buffer或ArrayBuffer的对象——它会尝试转成 base64 字符串，瞬间吃光内存 - 确认你用的是最新版
vscode-js-debug（内置）或debugpy>=2.0；旧版对Proxy/Map/Set的序列化有已知栈爆炸缺陷
launch.json 里哪些参数实际影响调试内存，哪些纯属误导
很多教程乱抄 node --max-old-space-size 到 env 或 args 字段，结果完全无效。VSCode 调试器启动子进程的方式严格区分 runtime 参数、环境变量、和调试协议配置。
真正起作用的只有：
-
"runtimeArgs"：只对 Node.js 有效，传给node二进制本身，例如["--max-old-space-size=4096", "--expose-gc"] -
"env"：只影响子进程环境，对 Node.js 内存无直接作用，但可设NODE_OPTIONS=--max-old-space-size=4096（注意：这在 Windows PowerShell 里要写成双引号包裹） -
"console": "integratedTerminal"：启用后，调试器不再走 VSCode 内置通道，而是起独立终端进程，此时runtimeArgs失效，必须靠终端 profile 里的node默认参数兜底 -
"python.defaultInterpreterPath"：必须指向你真实 venv 里的python，否则debugpy会 fallback 到系统 Python，而它的内存限制和你预期的不一致
以下参数完全无效，删掉省心："typescript.tsserver.maxMemory"、"editor.largeFileOptimizations"、任何带 memory 字样的用户级设置——它们不流经调试子进程。
调试中发现内存不降，别 reload，先 kill Extension Host
你看到的“调试内存没释放”，90% 是 Extension Host 进程卡住了。比如你在调试时点了 GitLens 的提交图，它后台拉取了 .git/objects 下几千个松散对象并缓存，这些数据挂在 Extension Host 堆里，和你的 debug session 无关。reload window 不杀它，内存照涨。
正确操作链：
- 按
Ctrl+Shift+P→ 输入Developer: Open Process Explorer，找到 “Extension Host” 行，记下 PID - 终端执行
kill -9 [PID]（macOS/Linux）或taskkill /f /pid [PID]（Windows） - 再运行
Developer: Show Running Extensions，确认列表清空 - 最后重启调试会话——此时 Extension Host 是干净的新进程，不会再继承旧缓存
最易被忽略的一点：VSCode 的调试器和 Extension Host 是两个完全独立的进程模型，它们的内存不共享也不同步。盯着调试控制台看内存数字，不如直接去 Process Explorer 看 Extension Host 的 RSS 值是否回落。
