web调试

浏览器里按一下F12，那个密密麻麻的面板就是web调试的战场。我见过太多人一打开DevTools就发怵，鼠标在Network和Console之间来回晃，像只迷路的蚂蚁。其实调试这事儿，说白了就是跟代码对话——你问它一句“你为啥这样”，它回你一个红色报错，你再顺着线索往下挖。

上周修一个页面白屏bug，用户反馈说打开就空白。我第一反应是看Console，果然，一行刺眼的红色：Uncaught TypeError: Cannot read properties of undefined。报错指向一个对象属性，可我明明初始化了。再往下看堆栈，发现是异步请求返回的数据结构变了——后端同事悄悄把字段名从userName改成了name，前端没同步。这种问题，Console里那行红色就是最好的破案线索。

但Console只是入口。真正让我觉得调试像侦探工作的，是Network面板。上次有个接口偶尔超时，用户反馈时好时坏。我打开Network，刷新页面，盯着那个请求的Timing标签页——Waiting (TTFB) 花了4.2秒，而DNS查询才0.3毫秒。问题不在网络，在服务器处理。后来发现是后端某条SQL查询没走索引，数据量一大就慢。你看，面板上那个小小的数字，直接帮你锁定了责任方。

调试也不全是技术活。有时候你盯着代码看了半小时，愣是找不出毛病，结果发现是缓存——浏览器缓存了旧的JS文件，你改的代码根本没生效。这种时候，Network面板里那个Disable cache复选框就是救命稻草。勾上它，刷新，世界清净了。我习惯开着DevTools就不关，哪怕只是写个简单的静态页面——谁知道什么时候会突然冒出个奇怪问题呢？

还有一次特别邪门，页面在Chrome里一切正常，换到Safari就布局错乱。我以为是CSS兼容性问题，查了半天没头绪。后来打开Safari的Web Inspector，看到Console里一条警告：Content-Security-Policy阻止了某个第三方脚本。原来那个脚本只在Safari里被拦截，导致某个功能没初始化，连带影响了样式。你看，不同浏览器的调试工具各有脾气，但核心思路一样——先看报错，再看网络，最后查存储。

说到存储，Application面板我平时用得少，但一旦碰上“用户登录状态不对”这种问题，它就是主角。上次测试说退出登录后还能访问受限页面，我打开Application，点开Local Storage，发现前端把token存了两个key——一个旧的没清掉，一个新的写进去了。代码里只读了新的，但旧的在某些逻辑里被当做了备用。清掉旧key，问题消失。这种问题，光看代码真发现不了，非得动手翻存储。

调试到最后，你会发现它拼的不只是技术，还有耐心和直觉。有时候你试了十几种方法都不行，去泡了杯咖啡，回来一眼就看出问题——某个变量名拼错了，或者某个条件写反了。那些看似高深的调试技巧，其实都是在无数次试错中磨出来的。工具就摆在那儿，F12一按就能用，但真正值钱的是你脑子里那张“问题地图”——知道去哪儿找线索，怎么判断线索靠不靠谱，以及，什么时候该关掉DevTools，去跟后端同事聊两句。