在.then()、.catch()和await关键位置设断点，可精准捕获Promise状态切换瞬间（pending→fulfilled/rejected），观察value/reason、调用栈及微任务队列；配合DevTools异步调用栈、Promise面板与Async选项，能高效定位状态锁死、隐式pending等典型问题。
直接在 .then()、.catch() 和 await 关键位置设断点，就能清晰看到 Promise 链中每一步的状态流转和返回值。关键不是“看链”，而是“看状态切换的瞬间”——pending → fulfilled 或 rejected 的那一刻，变量、调用栈、微任务队列都暴露得最真实。
在 .then() 和 .catch() 回调开头设断点
每个 .then() 和 .catch() 都是一个独立执行上下文，回调函数刚进入时，Promise 状态已经确定，value 或 reason 已就绪：
- 在
.then(callback)的callback第一行加断点，可立即看到上一个 Promise 解析出的 value（比如 API 返回的 data） - 在
.catch(error)入口设断点，能捕获被传递下来的 rejection reason，包括原始错误、字符串、甚至 undefined（说明 reject 被调用但没传参） - 注意：如果链中某步返回的是 Promise，当前
.then()拿到的不是最终结果，而是那个新 Promise 实例——可在断点处展开查看其[[PromiseState]]和[[PromiseResult]]（Chrome DevTools 中需启用“Enable JavaScript source maps”并使用原生代码调试）
在 await 表达式前后分别设断点
await 本质是语法糖，背后仍是 Promise 状态机。断点设对位置，能直观对比“挂起前”和“恢复后”：
- 在
await fetch(...)这行左侧行号处设断点：执行暂停，此时 Promise 处于 pending 状态，可检查请求参数、headers、URL 是否正确 - 在
await下一行设断点：代码恢复，此时 Promise 已 settled，response 对象已可用，可验证 status、ok、json() 是否可调用 - 若 await 的 Promise 被 reject，控制流会跳转到最近的
catch或外层try/catch，这时需同步在 catch 块设断点配合观察
利用 DevTools 的 “Async Call Stack” 和 “Promise” 面板
浏览器开发者工具已深度支持 Promise 调试，不止靠手动断点：
立即学习“前端免费学习笔记（深入）”；
- 勾选 Sources 面板右上角的 Async 选项，调用栈中会出现 “Promise.then”、“Promise.catch”、“async function” 等异步帧，能看清哪一层触发了哪一链
- 在 Console 中输入
debugger并触发 Promise 链，暂停后打开 “Scope” 面板，展开 Closure 或 Async 可见当前异步上下文绑定的变量 - Chrome 120+ 支持在 “Memory” 或 “Performance” 标签页中录制并筛选 “Promise” 事件，定位未处理的 rejection 或长时间 pending 的 Promise
识别状态锁死与隐式 pending 的典型场景
很多“链不动了”不是代码逻辑错，而是状态卡在 pending 无法推进，断点要针对性设在易堵点：
- 忘记 resolve/reject：在 Promise 构造函数内部的异步操作末尾（如 setTimeout 回调、fetch.then）设断点，确认
resolve()或reject()是否真的执行 - 返回非 Promise 但期望链式等待：比如
.then(() => doSomething())中doSomething()返回 undefined，下个.then()会立即执行且接收 undefined——在该行设断点，看返回值类型（console 中输入typeof result） - 微任务竞争：多个
Promise.resolve().then()同时注册，执行顺序依赖入队先后。可在每个then内部加console.log('step 1')并结合断点，对照 Sources > Breakpoints 列表确认触发顺序
