应使用 async/await 重写 Promise 链以确保断点可靠，启用异步堆栈追踪还原调用路径，为 catch 添加 debugger 捕获拒绝态，并用命名函数替代箭头函数提升调试精度。
直接在 Promise 回调里打个断点，往往停不住、停错位置，或者堆栈空荡荡——这不是断点失效，而是没进对异步上下文。关键在于让调试器能“跟进去”，而不是等它“偶然跳进来”。
用 async/await 重写，让断点像同步代码一样可靠
Promise 链（.then() 嵌套）本质是注册微任务，回调执行时原始调用栈早已退出。async/await 则把异步流程“挂起”在函数作用域内，调试器能完整保留上下文：
- 把
fetch('/api/user').then(res => res.json()).then(data => console.log(data))改成：async function getUser() {<br> const res = await fetch('/api/user');<br> const data = await res.json();<br> console.log(data); // 在这行打断点，data 已就绪，作用域清晰<br>} - await 行本身不会暂停执行，但下一行会等 Promise 完成后再进入，单步（F10）、步入（F11）、查看变量都自然可用
- Chrome DevTools 和 VS Code 都能准确映射 await 后的源码位置，不出现“断在匿名函数内部却找不到对应行”的情况
开启异步堆栈追踪，看清 Promise 是从哪发起的
即使你在 .then() 里打了断点，调用栈默认只显示 promise callback 这一层。启用异步堆栈后，能还原出完整的触发路径：
- Chrome DevTools：打开 Settings → Preferences → 确保 “Enable async stack traces” 已勾选（新版默认开启）
- 断点触发后，在 Call Stack 面板中会看到类似：
async function getUser→promise callback→then handler - 点击最上面的
async function getUser，编辑器自动跳转到原始调用处，快速定位是哪个请求、哪个参数或哪次状态变更引发的问题
给 catch 加 debugger，专抓被忽略的拒绝态
Promise 拒绝却不处理，控制台报错但断点不触发，问题就悄悄漏过去了。主动拦截可强制中断：
- 在链末尾加：
.catch(err => { debugger; console.error(err); })，一旦 reject 就停住，能看到 err.reason、堆栈、闭包里的 request 参数等 - 全局监听未捕获拒绝：
window.addEventListener('unhandledrejection', e => { debugger; });，复现失败场景时立即中断，不用反复猜哪一步崩了 - 配合
console.trace()或在 debugger 处展开e.promise，还能查到这个 Promise 是由哪个 fetch 或 setTimeout 触发的
别在箭头函数里打断点，改用命名函数提升可调试性
像 .then(data => process(data)) 这种写法，DevTools 很难把断点和源文件精确关联，尤其压缩后或多人协作时，容易断在错误的上下文里：
- 改成：
.then(handleUserData)，并单独定义function handleUserData(data) { /* 在这里打断点 */ } - 命名函数有明确标识，Call Stack 中显示函数名而非
anonymous，变量作用域也更稳定 - 如果必须内联，至少加 JSDoc 注释，如：
.then(/** @param {User} data */ data => { ... })，部分编辑器能据此辅助定位
