Chrome DevTools Sources面板支持行断点、条件断点和事件监听器断点；动态脚本需启用source maps才能正确调试；console.table、group、debugger、time及JSON快照等是log的高效替代；Network面板需结合Headers、Response和Timing分析请求失败根因；未捕获Promise错误应通过unhandledrejection事件监听并配置source-map定位。
Chrome DevTools 的 Sources 面板怎么设断点
断点是调试 JavaScript 最直接的入口，Sources 面板支持三种常用方式：行断点、条件断点、事件监听器断点。点击行号左侧灰色区域可设行断点；右键行号可添加条件断点（例如 user.id === 123）；右侧 Event Listener Breakpoints 下勾选 click 或 fetch 可在对应事件触发时暂停。
容易忽略的是：动态插入的脚本（如通过 eval() 或 new Function() 创建）默认不显示在 Sources 列表中，需在右上角三个点菜单里开启 Enable JavaScript source maps 并确保有 sourcemap；否则断点会失效或跳转到压缩后代码。
console.log 不够用时，用哪些替代方案
console.log() 看变量值没问题，但查异步链路、作用域污染或性能瓶颈就力不从心。更有效的选择包括：
-
console.table(data)：适合查看数组或对象列表，自动格式化为表格 -
console.group('API call')+console.groupEnd()：折叠日志分组，避免混杂 -
debugger语句：写在代码里，等价于 Sources 面板手动打的断点，但要注意上线前必须删掉，否则用户打开控制台就会卡住 -
console.time('fetch')/console.timeEnd('fetch')：测某段逻辑耗时，比手动记时间戳直观
注意：console.log(obj) 输出的是引用，后续修改 obj 会影响控制台显示内容——想看快照得用 console.log(JSON.parse(JSON.stringify(obj))) 或展开后右键 Store as global variable 再 copy()。
立即学习“Java免费学习笔记（深入）”；
Network 面板怎么看请求失败的真实原因
看到一个红字 401 或 500 不代表后端问题。先点开该请求，在 Headers 标签页确认 Request URL 是否拼错、Referrer 是否被拦截；在 Preview 或 Response 里看返回体是否含错误详情（比如 {"error": "token expired"}）；再切到 Timing 查是否卡在 Stalled（常因连接池满或 DNS 慢）或 Waiting (TTFB)（服务端响应慢）。
常见陷阱：前端发了 fetch('/api/user')，但 Network 显示请求发到了 http://localhost:3000/api/user，而实际后端跑在 8080 端口——这时要检查 proxy 配置或后端 CORS 设置，而不是改 JS 代码。
如何快速定位未捕获的 Promise 错误
页面白屏或功能异常但控制台没报错？很可能是 Promise 被 reject 后没接 .catch()。Chrome 和 Edge 在 Console 中默认会提示 Uncaught (in promise) Error: ...，但 Firefox 默认不显示——需手动打开设置里的 Enable logging of Promise rejections。
实操建议：
- 全局监听：
window.addEventListener('unhandledrejection', e => { console.error('Unhandled rejection:', e.reason); }); - 开发时加临时兜底：
Promise.reject(new Error('test')).catch(console.error) - Vite / Webpack 项目可在
vite.config.js或webpack.config.js中启用devtool: 'source-map'，否则堆栈指向bundle.js:123这类位置毫无意义
真正难缠的是微任务队列中的错误——比如 setTimeout 里抛错能看见，但 queueMicrotask(() => { throw new Error() }) 会直接进 unhandledrejection，且堆栈极短，必须靠 unhandledrejection 事件捕获。
