VSCode调试时需启用异常断点而非普通断点才能捕获异常：Node.js勾选Uncaught Exceptions，Python勾选Raised Exceptions，JS/TS需额外启用Pause on caught exceptions和Uncaught Promise Rejections。
VSCode调试时根本看不到异常堆栈？
默认情况下，VSCode的Node.js或Python调试器不会在异常发生瞬间中断——它只在你打了断点的地方停。没断点，错误就直接抛出、打印、退出，你连throw那行在哪都看不到。
真正起作用的是「异常断点」（Exception Breakpoints），不是靠改launch.json里的参数“捕获”异常，而是让调试器主动监听并拦截特定异常类型。
- Node.js：需勾选「Uncaught Exceptions」或手动添加
throw、unhandledrejection等事件监听断点 - Python：在调试面板点击「Breakpoints」→ 勾选「Raised Exceptions」，或展开后单独勾选
Exception、KeyError等具体类 - 前端JS/TS：Chrome调试器支持「Pause on caught exceptions」，但默认只停未捕获的；若想停在
try/catch内部，得手动勾选该选项（调试面板右上角⋯→「Pause on caught exceptions」）
launch.json里哪些配置真影响异常拦截？
launch.json本身不处理异常逻辑，但它决定调试器用什么模式启动、是否传递关键标志。错配会导致异常断点完全失效。
-
"stopOnEntry": false—— 这个和异常无关，别被名字误导；它只控制是否一启动就暂停在第一行 -
"console": "integratedTerminal"—— 如果设成externalTerminal，VSCode就无法接管进程输出，异常断点可能触发但你看不到上下文 - Node.js必须加
"runtimeArgs": ["--inspect-brk"]（调试启动）或确保"attach"模式连对了端口；否则调试协议不通，断点全失效 - Python要确认
"justMyCode": true（默认）——设为false会停进标准库异常抛出处，干扰大，一般不需要
为什么断点打了却从不停在throw那一行？
常见原因不是配置漏了，而是异常类型没匹配上。比如你只勾了Exception，但实际抛的是TypeError子类，在某些语言里不会自动触发父类断点。
- Node.js：「Uncaught Exceptions」只拦真正没被
catch住的；如果代码里写了try { ... } catch (e) { }，异常就被吞了，断点不会触发 - Python：勾选
Exception能拦所有，但勾选BaseException反而可能拦不到——因为SystemExit这类是它的子类，但调试器实现常做白名单过滤 - TS/JS：异步异常（如
Promise.reject()）默认不触发断点，必须额外勾选「Uncaught Promise Rejections」
全局错误处理不能替代调试断点
有人在代码里加window.addEventListener('error')或process.on('uncaughtException')，以为这样就能“捕获异常”，其实这只是事后记录，调试器早跳过去了，调用栈也丢了大半。
- 这类监听只能拿到
error.message和error.stack字符串，没法看到变量值、执行上下文、源码定位 - Node.js中
unhandledRejection监听甚至不包含原始throw位置，只告诉你哪个Promise崩了 - 真正要调试，必须依赖调试器的异常断点机制，而不是靠代码里补监听
异常断点不是开关一开就万事大吉，它高度依赖运行时环境、调试协议版本、以及你勾选的异常粒度——同一份代码，在WSL里跑和在Windows原生终端跑，有时断点行为都不一样。
