浏览器调试
打开开发者工具的浏览那一刻，你其实是器调在跟浏览器做一笔交易：它把内部运转的细节摊开给你看，代价是浏览你得知道自己在找什么。我见过太多人只把F12当“查看元素”用，器调改个颜色就关掉，浏览这跟买了台显微镜只拿来当放大镜使没什么区别。器调
先说一个我上周碰到的浏览真实场景。同事的器调页面在手机上白屏，桌面端一切正常。浏览他查了两小时CSS和JS，器调最后我让他打开Chrome的浏览远程调试，连上手机一看——Network面板里那个关键接口在移动网络下返回了302，器调跳转到了一个不存在的浏览地址。桌面端因为缓存命中了旧响应，器调根本没发出请求。浏览这个bug的根源跟CSS、JS毫无关系，但如果你不打开Network面板，永远猜不到。
所以调试的第一步从来不是“看代码”，而是“看数据”。Console面板是最直接的入口，但多数人只把它当报错窗口。其实你可以在里面做很多事：console.table()能把数组对象打印成表格，比展开嵌套结构快十倍；console.time()和console.timeEnd()夹住一段逻辑，控制台直接吐出耗时毫秒数。我习惯在关键函数入口打一个console.count()，跑一遍页面就知道哪个函数被调了几百次——性能问题往往就藏在这种地方。
Sources面板才是真正的战场。断点谁都会打，但条件断点用的人少。比如一个循环里只有i === 47时数据才异常，你没必要按47次继续。右键行号选“Add conditional breakpoint”，输入条件，浏览器只在那一次停下来。还有更隐蔽的：在Sources里按Ctrl+Shift+F全局搜索，能跨所有加载的JS文件找字符串。我靠这招找到过一个第三方库偷偷上报用户行为的代码，文档里完全没提。
Network面板的细节密度最高。把请求按Size排序，排在最前面的往往是图片或字体，但真正拖慢首屏的是Waterfall里那些排队等待的接口。看Timing标签，如果Stalled或Queueing占了大头，说明浏览器并发连接数被打满了，该考虑拆分域名或合并请求。我见过一个页面加载了80多个小图标，每个都单独发请求，Queueing时间加起来超过3秒。换成雪碧图或base64内联，首屏直接快了一半。
Performance面板录一段操作，火焰图能告诉你主线程到底在忙什么。长任务（超过50ms的黄色块）是卡顿的元凶。点开一个长任务，看它下面挂着的函数调用栈，经常能发现某个JSON.parse处理了巨型数据，或者一个循环里反复操作DOM。有个经验：如果火焰图里出现大段空白但CPU占用却很高，去Memory面板查内存泄漏，多半是闭包或事件监听没清理。
Application面板管的是“状态”。Local Storage、Session Storage、Cookies、IndexedDB全在这里。调试登录态问题时，直接看Cookie的Expires和HttpOnly标志比翻代码快。我遇到过一个诡异情况：用户登出后刷新页面又自动登录了。打开Application一看，Local Storage里存了个token，登出逻辑只清了Cookie没清它。这种问题在代码里搜“logout”可能搜不到，但在存储面板里一眼就能看见。
最后说个习惯：把开发者工具的面板布局调成你顺手的顺序。我通常把Console放最下面，Network和Sources并排。每次打开都按固定顺序扫一遍——Console有无报错、Network有无红色请求、Sources有无断点残留。这套动作花不了十秒，但能省下大量“盲猜”的时间。浏览器调试说到底不是学几个快捷键，而是建立一种“先看证据再改代码”的条件反射。