断点命中后卡住几秒才进Debug Console，主因是调试器暂停时默认全量展开作用域对象，触发递归解析与AST遍历；应配置"maxChildren"和"maxStringLength"限制加载深度，并在launch.json中添加"skipFiles": ["**"]及settings.json中完善files.watcherExclude排除node_modules等目录。
调试运行时响应慢，90% 以上不是 VSCode 本身的问题，而是调试器初始化、变量加载深度或文件监视拖垮了主线程。 关键不是“等它变快”，而是砍掉调试器启动和暂停时的冗余开销。
为什么断点命中后卡住几秒才进 Debug Console
Node.js 或 Python 调试器在暂停时默认尝试展开整个作用域对象（包括 global、process、大型数组），递归解析会触发大量 AST 遍历和内存读取。尤其当对象含循环引用或嵌套过深时，VSCode 渲染线程直接被阻塞。
- 检查你的
launch.json是否设置了"maxChildren"和"maxStringLength"；没设就等于不限制，等于给调试器发了“全量加载”指令 - Node.js 项目务必加
"skipFiles": ["<node_internals>/**"]</node_internals>，否则每次暂停都要扫描 V8 内部模块 - Python 用户注意：如果用了
ptvsd（旧版）或未配置justMyCode，调试器会钻进site-packages里找断点
files.watcherExclude 配不全导致调试器“假死”
你点下 F5，VSCode 暂停了，但变量窗空白、Call Stack 不刷新、甚至 Debug Console 输入无响应——这往往不是调试器崩了，而是 Code Helper (Renderer) 进程 CPU 被文件监视器吃满，根本没资源渲染 UI。
- 必须在项目根目录的
.vscode/settings.json中写，用户级设置无效 - 最低要求：
"**/node_modules/**": true、"**/dist/**": true、"**/.git/**": true、"**/__pycache__/**": true - Python 项目补：
"**/venv/**": true、"**/.mypy_cache/**": true；前端补："**/build/**": true、"**/out/**": true - 改完后关掉整个 VSCode 窗口再重开——缓存不刷新，配置等于没写
code-runner 干扰调试流程
如果你习惯用 Ctrl+Alt+N 运行脚本，又同时开了调试器，两者会争抢终端控制权或触发重复保存。更隐蔽的问题是：某些 code-runner.executorMap 命令（比如带 cd $dir && 的）会在调试前偷偷执行一次 shell 切换，导致工作目录错乱、路径解析失败、甚至 input() 卡死。
- 调试期间临时禁用
code-runner.saveFileBeforeRun，避免保存 → 格式化 → 保存 → 触发 Live Server → 干扰调试上下文 - 确认
code-runner.runInTerminal是true，否则输出面板无法响应input()，你会误以为“调试卡在输入” - 别让
code-runner和Python扩展共用同一终端实例：在settings.json中设"python.terminal.executeInFileDir": false
真正卡住调试响应的，从来不是“断点逻辑”，而是那些默认开启却没人关的递归加载、全量监视和跨扩展协作。最有效的优化，往往是一行 maxChildren 配置 + 一个 **/node_modules/** 排除 —— 但这两处，恰恰最容易被忽略。
