VSCode调试时Uncaught Exceptions不暂停是因为默认只捕获未被try/catch处理且冒泡至全局的异常，而框架内吞掉的异常（如React渲染错误、未catch的Promise拒绝）需手动配置"breakOnException": "uncaught"并注意大小写及环境适配。
VSCode调试时为什么Uncaught Exceptions不暂停？
因为默认只捕获“未处理的异常”（即没被try/catch包裹、最终冒泡到全局的错误），而很多异常其实在框架或库内部就被吞掉了——比如React组件渲染错误、Promise里抛出但没.catch()的异常，它们属于Uncaught Exceptions，但VSCode默认不中断。
常见现象：console.error有输出，调试器却不停；断点设在throw那行，但根本没走到。
- 确保你用的是
Node.js或Chrome调试器（不是仅靠console看） - 检查
launch.json中是否启用了"stopOnEntry": false——它不会影响异常，但容易让人误以为整个调试配置失效 -
Uncaught Exceptions和Caught Exceptions是两个独立开关，别混淆
怎么在launch.json里开启未处理异常暂停
核心就一条：加"breakOnException": "uncaught"，不是"all"也不是"caught"。
示例（Node.js场景）：
{
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Launch Program",
"program": "${file}",
"breakOnException": "uncaught"
}
]
}
- 如果是Chrome调试前端代码，把
"type"换成"pwa-chrome"，同样支持"breakOnException": "uncaught" - 注意大小写：
"uncaught"必须全小写，写成"Uncaught"会静默失效 - 该设置只对当前
launch.json配置生效，切换配置需逐个检查
Promise拒绝未处理时为啥还是不停？
因为Promise.reject()本身不触发Uncaught Exception，只有它最终没被.catch()或await捕获、且进入unhandledrejection事件时才算。
VSCode的breakOnException: "uncaught"默认**不监听unhandledrejection事件**，得额外加配置：
- Node.js：加上
"console": "integratedTerminal"并确保node --trace-uncaught没被覆盖（但更稳的是改代码加process.on('unhandledRejection', ...)打日志） - Chrome/PWA：需要在
launch.json里显式启用"breakOnException": "uncaught"+"enableNetwork": true（部分版本依赖此触发事件监听） - 最可靠做法：在代码开头加
window.addEventListener('unhandledrejection', e => { debugger; });（前端）或process.on('unhandledRejection', () => { debugger; });（Node.js）
调试器停了，但堆栈指向internal或node_modules深处
这不是设置错了，而是异常源头被封装了。比如axios请求失败后throw，VSCode中断位置常在node_modules/axios/lib/core/settle.js，而非你调用axios.get()的地方。
- 优先在你自己的异步函数里加
try/catch，并在catch里放debugger——比依赖自动中断更可控 - 在VSCode调试面板的
CALL STACK里往上翻，找第一个属于你项目路径的帧（通常带src/或app/） - 如果堆栈全是
internal/*，大概率是async链断裂或Promise没正确链式传递
真正难的不是打开开关，而是区分“异常被谁吞了”和“异常从哪来”——这两者经常不在同一层代码里。
