不是调试器坏了，而是V8引擎对await暂停点映射依赖正确的调试协议类型和准确的source map路径；TypeScript/打包项目需配置sourceMaps、outFiles及sourceMapPathOverrides，避免断点悬空。
断点打在await行却跳过，是不是调试器坏了？
不是调试器坏了，是 V8 引擎对 await 的暂停点映射依赖两个前提：正确的调试协议类型 + 准确的 source map 路径。VSCode 默认用 pwa-node 启动器时，若项目含 TypeScript 编译或 Webpack 打包，sourceMapPathOverrides 配置不匹配就会让断点“悬空”——看着停在 await 行，实际执行流已滑过去。
- 确认
launch.json中"type"是"pwa-node"（不是旧版"node"）且"request"为"launch" - TypeScript 项目必须设
"sourceMaps": true，并显式配置"outFiles"指向.js输出目录（如["./dist/**/*.js"]） - 避免在
new Promise((resolve) => { ... })构造函数内打断点——V8 可能因内联优化跳过该帧 - 优先把断点打在
await所在行，或async函数第一行，而非 Promise 创建处
Promise.all 里某个请求失败，断点停在哪？
Promise.all 短路后堆栈只显示调用点，根本看不出是哪个子 Promise 拒绝。靠断点“猜”效率极低，得让错误暴露得更早、更具体。
- 不要直接
await Promise.all([p1, p2, p3])，改用await Promise.allSettled([p1, p2, p3])—— 它不会短路，返回每个 Promise 的状态和值/原因 - 若必须用
Promise.all，在每个子 Promise 后加.catch(e => { console.error('p1 failed:', e); throw e; })，断点打在console.error行可定位具体失败项 - 调试时在 Debug Console 输入
await p1单独触发并查看其结果，比等整个 all 执行完更快
异步回调里断点失效，比如 setTimeout 或 fs.promises.readFile
这类断点常失效，不是配置问题，而是你把断点下在了“注册时机”，而非“执行时机”。setTimeout(() => { /* 这里断点不可靠 */ }, 100) 中的回调属于 macrotask，调试器不保证在事件循环下一帧自动停靠。
- 把逻辑抽成独立
async函数，例如：async function readA() { return await fs.promises.readFile('a.txt'); }，然后在调用处const data = await readA();打断点 - 对
process.nextTick或queueMicrotask，同样封装后await调用，避免依赖调度时机 - 绝对不要在回调函数里写
debugger;并指望它稳定触发——Node.js 优化可能移除该语句，且 VSCode 不强制注入
为什么变量显示 pending，但代码明明写了 await？
Variables 面板默认只同步渲染当前帧的局部变量，Promise 状态需主动求值。显示 Pending 不代表没 await，只是调试器还没完成解析。
- 在 Debug Console 直接输入变量名（如
result）回车，会强制触发 Promise 的then并输出 resolved 值 - 右键 Variables 面板中的 Promise 对象 → “Re-evaluate”，刷新其状态
- 如果始终卡在
Pending，检查是否漏了await（比如写了fetch('/api')没await），此时变量类型确实是Promise而非响应体 - 启用 Async Call Stack（Debug 视图右上角齿轮图标 → 勾选）才能看清 await 链路，否则调用栈会断在
internal/process/task_queues.js
异步调试最易被忽略的是：断点位置必须落在“可被同步捕获的执行路径”上，而不是注册回调的瞬间；Promise 状态需要手动触发求值，不能依赖面板自动刷新；而 Promise.all 的短路行为会让错误溯源变成盲区——得用 allSettled 或显式 .catch 把拒绝原因提前拽出来。
