VSCode中async/await断点失效的根本原因是V8未将await暂停点映射回源码行，需同时满足启用Node.js异步追踪、正确source map、断点位于可暂停位置三个条件。
VSCode 里 async/await 断点不中断，不是代码写错了，而是调试器没拿到异步调用栈的映射权——必须同时满足三个硬条件：启用 Node.js 异步追踪、正确 source map、断点落在可暂停位置。
为什么 await 行断点经常跳过？
根本原因是 V8 默认不把 await 暂停点映射回源码行。即使你打了断点，VSCode 调试器看到的只是 microtask 队列里的匿名函数，无法关联到 async 函数内的具体 await 行。
- 必须在
launch.json的env字段中显式加："PROMISE_DEBUG": "1"和"NODE_OPTIONS": "--enable-source-maps"（缺一不可） - 确保
type是"node"，不是"pwa-node"或旧版"node2" - 不要在
Promise构造函数内部打断点（如new Promise(resolve => { /* 这里打点无效 */ })），V8 优化后可能直接跳过 - TypeScript 项目需同时设
"sourceMaps": true和"inlineSources": true，否则变量名和行号都对不上
怎么让 setTimeout / fs.promises.readFile 断点真正生效？
这些属于事件循环调度的回调，调试器不会自动“等下一帧”。直接在回调里打点或写 debugger 不可靠——Node.js 可能已优化掉该语句，或 VSCode 未在回调执行时激活调试上下文。
- 把逻辑封装进
async函数，再await调用它（例如await loadFile()），断点打在await行或函数首行 - 对
process.nextTick或queueMicrotask同样处理：包一层async+await，别依赖调度时机 - 避免
setTimeout(() => { debugger; }, 100)—— 这种写法在 --optimize 模式下大概率失效 - 如果必须调试注册阶段（比如检查定时器是否设置成功），改用
Debug Console手动查globalThis.setTimeout或timers.active()
Promise.all 失败时怎么定位具体哪个子 Promise 拒绝？
Promise.all 短路后，堆栈只显示调用点，错误信息里不带原始拒绝来源。Variables 面板也只显示最终 AggregateError，看不到各子项状态。
- 在
Debug Console中手动执行Promise.allSettled([...])替代Promise.all，能拿到每个子 Promise 的status、value或reason - 若不能改代码，在
catch块里打断点，然后在Debug Console输入error.errors[0]（或遍历error.errors）查看各拒绝原因 - 右键 Variables 面板中的
error→ “Re-evaluate”，有时能刷新出未截断的完整错误链 - 注意：如果子 Promise 是
fetch()未await，它本身仍是 pending 状态，不是 rejected —— 先确认是否漏了await
调试插件或 Electron 主进程时特别容易失效？
VSCode 插件运行在 Electron 环境，主进程和渲染进程混合加载，且默认禁用异步堆栈追踪。此时仅配 sourceMaps 和 type: "node" 不够。
- 必须在
launch.json的env中强制开启："ELECTRON_ENABLE_LOGGING": "1"（辅助排查加载失败）、"PROMISE_DEBUG": "1"、"NODE_OPTIONS": "--enable-source-maps" - 如果插件用了 Webpack 打包，需确保构建时生成
devtool: "source-map"，并在launch.json中补全sourceMapPathOverrides映射原始路径 - 遇到断点变空心圆，先检查左下角状态栏是否显示「正在调试」及环境名（如「Extension Development Host」），没显示说明进程根本没连上调试协议
- Electron 渲染进程调试需额外配
"type": "pwa-chrome"，和主进程配置完全隔离，不能混用同一组env
最常被忽略的一点：所有异步调试的前提是——你停在的那帧，必须是 async 函数体内的同步执行上下文。一旦跳出（比如按了 Shift+F11），后续微任务里的代码就脱离原始调用栈，断点再难精准捕获。
