VSCode调试async/await断点不触发是因source map未启用或ESM配置不当：需在launch.json设"sourceMaps": true，ESM项目加"--enable-source-maps"，TS项目配"module": "ESNext"并确保.map文件存在。
VSCode 调试 async/await 时断点不触发或跳过
这不是 Node.js 版本或语法问题，而是 VSCode 的 launch.json 配置未启用源映射（source map）或未正确识别 ES 模块上下文。Node.js 本身从 v7.6+ 就原生支持 async/await，但调试器依赖 sourcemap 才能将转译后的代码（如 TypeScript 或 Babel 输出）准确映射回原始 async 函数位置。
常见现象包括：在 await 行设断点，调试时直接跳过；step into 进入 Promise 回调失败；调用栈显示匿名函数而非原始 async 函数名。
- 确保启动配置中
"sourceMaps": true，且项目已生成有效的.map文件（如tsc --sourceMap或babel --source-maps） - 若用 ESM（
type: "module"），必须在launch.json中显式指定"runtimeArgs": ["--enable-source-maps"]（Node.js ≥ v14.18.0） - 避免混用
outFiles和resolveSourceMapLocations：前者易因路径不匹配失效，推荐后者配合 glob 排除 node_modules
launch.json 中 runtimeVersion 和 runtimeExecutable 的取舍
VSCode 默认调用系统 PATH 中的 node，但异步调试稳定性高度依赖 Node.js 版本行为一致性。v16–v20 对 async 堆栈跟踪修复较多，而 v14 在某些 Promise 链场景下会丢失帧。
- 不要写死
"runtimeExecutable": "/usr/bin/node"—— 它绕过 nvm/nodenv 环境，导致调试器用错版本 - 改用
"runtimeVersion": "18.17.0"（需 VSCode 1.82+），VSCode 会自动匹配已安装的对应版本（通过node -v检测） - 若项目依赖
nodemon或ts-node，必须用"runtimeExecutable"指向它们，但需额外加"--inspect-brk"参数，并确认其底层 Node 版本 ≥ v16
TS + Node ESM 项目调试 async 函数失败的典型配置
TypeScript + ESM 是当前最易出问题的组合：TS 编译默认输出 CommonJS，而 "type": "module" 强制 ESM，导致 require() 报错、source map 加载失败、await 断点失效三连。
-
tsconfig.json必须含："module": "ESNext"、"target": "ES2020"、"sourceMap": true、"outDir": "./dist" -
launch.json中禁用"protocol": "inspector"（旧协议不兼容 ESM），改用默认"protocol": "auto" - 入口文件后缀必须为
.mjs或在package.json中声明"type": "module"，否则 Node 仍按 CJS 解析，import报错且 source map 不加载
调试时 await 后续代码无法 step over / step into
这不是配置问题，是 V8 调试器对 microtask 队列的处理限制：Promise resolve 后的 then 或 await 后续语句属于 microtask，调试器无法像同步代码那样逐行停顿。
- 不要在
await fetch(...)后立刻设断点——它可能因网络延迟未 resolve，断点被忽略；改用debugger语句或在await行本身设断点 -
step into对await无效（它不是函数调用），真正可 step into 的是Promise构造函数或自定义 thenable 的then方法 - 复杂 Promise 链建议拆成独立
async函数，便于单步和变量观察；避免一行多个await连写
package.json 的 "type" 字段与 tsconfig.json 的 "module" 是否真正对齐，以及 dist 目录下是否真实存在 .map 文件（注意 webpack/ts-node 等工具可能默认不输出到 dist）。 
