async-await异常堆栈常被promise截断，因v8为区分同步/异步路径而丢弃await前的调用帧；可通过启用--async-stack-traces、手动注入上下文或使用error.cause增强可追溯性。
async-await 中抛出的异常堆栈信息往往被 Promise 封装层“截断”，导致原始错误位置难以定位。关键在于理解 V8 引擎对异步调用栈的处理机制，并主动保留上下文。
默认堆栈为何不完整
当 await 后的 Promise 被 reject，错误会经由 Promise 链向上冒泡，V8 为避免混淆同步/异步调用路径，会丢弃 await 行之前的同步调用帧（如函数调用链），只保留 Promise 构造或 reject 处的堆栈。例如：
async function foo() {await bar(); // 若 bar() 内部 throw，此处不会出现在 stack 中
}
async function bar() {
throw new Error('oops');
}
启用 async stack traces（Chrome / Node.js ≥12）
现代 V8 支持异步调用栈追踪，但需确保环境开启相关支持：
- Chrome DevTools：默认开启，直接在 Console 或 Sources 面板查看完整 async stack
- Node.js：启动时加 --async-stack-traces 参数（v12+ 默认启用，但某些旧版本或打包环境可能关闭）
- VS Code 调试：launch.json 中设置 "runtimeArgs": ["--async-stack-traces"]
手动增强错误上下文
当运行时无法保证 async stack 可靠时，可主动注入位置信息：
- 在关键 await 前捕获并重抛错误：
try {
await apiCall();
} catch (err) {
err.message = `[apiCall] ${err.message}`;
err.stack = `${err.stack}\n at apiCall (service.js:42)`;
throw err;
} - 使用 error.cause（ES2022）关联原始错误：
throw new Error('Failed to process user', { cause: originalErr }); - 避免裸 throw，优先包装为带语义的自定义错误类，构造时记录 new Error().stack 快照
调试技巧与工具建议
精准定位依赖可观测性与工具协同：
- 在 Chrome DevTools 的 “Console” 中右键错误 → “Reveal in debugger”，可跳转到原始 throw 行
- 使用 console.trace() 在 await 前打点，辅助比对执行路径
- 配合 source map（尤其 TypeScript 或打包后代码），确保 devtool 能映射回源码行号
- Node.js 中可用 node --inspect + Chrome DevTools，断点设在 catch 块，展开 error.stack 查看完整异步帧
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
