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，比反复猜逻辑更可靠。 
