javascript怎样进行错误调试

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 无效。

正确做法分两种场景：

• 使用 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() 定位调用链。