17370845950

Chrome DevTools调试三大核心方式：行断点、debugger语句和条件断点；配合console.table/console.group优化日志；Network面板查请求真实状态；Sources面板借助source map实时编辑代码。

Chrome DevTools 断点调试最常用三种方式

直接在源码行号左侧单击打断点，是最直观的方式；但实际开发中容易忽略的是 debugger 语句和条件断点——它们能避开重复刷新、精准拦截特定逻辑分支。

• debugger 语句写在 JS 代码里，执行到时自动触发暂停，适合临时插入、无需打开 Sources 面板；注意上线前务必删除，否则用户也会卡住
• 右键行号打的断点可设「条件」，比如 user.id === 123，避免在大量循环中手动按 Resume
• 函数断点（Breakpoints 面板里的 Event Listener Breakpoints 或 XHR/fetch Breakpoints）比行断点更适合定位异步触发时机

console.log 不够用时，用 console.table 和 console.group

当打印对象数组或嵌套结构时，console.log 很难快速看清字段对齐和层级关系，而浏览器原生支持的增强方法能省去手写格式化的时间。

• console.table(data) 对数组或键值对对象自动转成表格，支持点击列头排序，特别适合查看 API 返回的列表数据
• console.group('API call') + console.groupEnd() 把多次日志收折起来，避免被中间其他 log 冲散上下文
• 别用 console.log(obj) 打印正在修改的对象——它显示的是「展开时的快照」，不是打印那一刻的值；改用 console.log(JSON.parse(JSON.stringify(obj))) 或断点查看 scope

Network 面板查 fetch/XHR 失败的真实原因

看到控制台报 Failed to fetch 或状态码 500，不代表后端一定出错；Network 面板才能暴露真实链路问题。

• 点击请求条目，在 Headers 标签页确认 Request URL 是否拼错、Referrer 是否被拦截、Content-Type 是否匹配（如传 JSON 却没设 application/json）
• 在 Preview 或 Response 标签页看返回体，有时后端返回了 200 但 body 是错误描述，前端却只判 status
• 勾选 Disable cache 再重发请求，排除本地缓存导致的旧响应干扰

Sources 面板里快速定位和修改运行时代码

线上 JS 压缩后难以调试，但 DevTools 支持 source map 映射和实时编辑，关键是要知道在哪找入口、怎么生效。

立即学习“Java免费学习笔记（深入）”；

• 压缩代码的 .js 文件旁出现 webpack:// 或 src/ 路径，说明 source map 加载成功；找不到就检查构建配置是否输出 devtool: 'source-map'
• 在 Sources > Page 下找到原始文件，双击打开，直接编辑 → 按 Ctrl+S（Win）或 Cmd+S（Mac）保存，会立刻重载该模块（仅当前页面有效）
• 改完别忘了复制代码回编辑器，DevTools 的修改不持久，刷新页面就丢

function handleUserClick(id) {
  debugger; // 这里会停住，方便看 id 和 this 上下文
  fetch(`/api/user/${id}`)
    .then(r => r.json())
    .then(data => {
      console.table(data.permissions); // 比 console.log 更清晰
      console.group('User profile loaded');
      console.log('id:', id);
      console.log('data:', data);
      console.groupEnd();
    });
}

调试真正卡住的地方，往往不是语法错误，而是数据状态和时序判断偏差。多看 Scope、Watch Expressions 和 Network 的真实 payload，比反复猜逻辑更可靠。