Chrome DevTools 的 console.error 不会中断执行但能精准定位错误位置，配合“Pause on caught exceptions”、堆栈追踪和文件行号跳转可高效调试；需规范输出格式、正确处理 Promise rejection、慎用 debugger 并确保 source map 正确映射。
Chrome DevTools 的 console.error 不会中断执行，但能精准定位错误位置
很多开发者以为 console.error 只是“打印一下”，其实它在调试中真正价值在于配合 DevTools 的「Pause on caught exceptions」和堆栈追踪。当你看到报错信息里带 Uncaught TypeError: Cannot read property 'x' of undefined，别急着改代码——先点开右侧的文件名和行号链接，直接跳转到出问题的那行。
实操建议：
- 在可疑逻辑前加
console.error('before calc', obj)，比console.log更易被 DevTools 过滤聚焦 - 右键控制台里的错误消息 → 「Reveal in Console」可快速定位同一类错误的多次发生点
- 避免只打
console.error(err)：改成console.error('API fetch failed:', err?.message, err?.stack)，否则异步错误的stack会被截断
try/catch 捕获不到 Promise rejection，必须用 .catch() 或 await + try
这是最常踩的坑：写了 try { fetchData() } catch(e) { ... } 却发现错误根本没进 catch 块。因为 fetchData() 返回的是 Promise，同步的 try/catch 对异步 rejection 无效。
正确做法分两种场景：
立即学习“Java免费学习笔记（深入）”；
- 使用
async/await：必须包在try内部，且await不能漏掉，否则还是走不到catch - 使用
.then().catch()：注意.catch()必须紧接在可能 reject 的 Promise 后，中间插个.then()但没返回新 Promise 就会吞掉错误 - 全局兜底：在浏览器中监听
window.addEventListener('unhandledrejection', e => {...})，用于捕获漏掉的 Promise 错误
示例对比：
fetch('/api').then(res => res.json()).catch(err => console.error('network error:', err)) // ✅try { fetch('/api').then(...).catch(...) } catch(e) { ... } // ❌ 无意义debugger 语句不是万能的，它依赖 DevTools 是否开启且未禁用
debugger 是最轻量的断点方式，但它不会自动触发——前提是当前页面的 DevTools 是打开状态，且「Disable JavaScript」或「Blackbox scripts」没误设。常见现象是加了 debugger 却毫无反应，其实是 DevTools 被关掉了。
使用时注意：
- 上线前务必删掉或用构建工具自动移除（如 Webpack 的
drop_debugger插件） - 在条件分支里加
debugger比在函数开头更高效，例如：if (user.role === 'admin') debugger - 配合条件断点更准：右键行号 → 「Edit breakpoint」→ 输入
user.id === 123，避免每次循环都停
source map 映射失效时，压缩代码的错误行号完全不可信
本地开发时错误指向源码没问题，但部署后看到 app.min.js:123:456 就抓瞎？那大概率是 source map 没正确生成或加载。关键不是“有没有”，而是“路径对不对”。
检查三件事：
- 构建产物目录下是否存在
app.min.js.map文件，且内容是合法 JSON -
app.min.js文件末尾是否有注释行：//# sourceMappingURL=app.min.js.map，路径必须相对于 JS 文件位置 - 浏览器 Network 面板里确认
app.min.js.map返回 200，且响应头没有X-Content-Type-Options: nosniff拦截
Vue/React 项目常因 devtool: 'source-map' 配置在 production 模式下被覆盖而失效，得显式写成 devtool: process.env.NODE_ENV === 'production' ? 'source-map' : 'eval-source-map'。
复杂点在于：source map 本身也可能出错——比如映射了错误的原始文件名，这时候错误堆栈显示的 utils.ts:42 实际对应的是编译前的第 18 行。遇到这种，只能回退到加 console.trace() 定位调用链。
