页面出问题时，先看 Console 再看 Network 更容易收住范围

浏览器里出现白屏、按钮没反应、数据不显示时，很多人的第一反应还是回编辑器里盯代码。但真到项目节奏快的时候，这种做法经常会让人越看越散。Chrome DevTools 真正有用的地方，是它能先帮你把问题范围收住。

Console 给的是“现在已经暴露出来的线索”

如果脚本语法错了、对象未定义、某个插件没有加载成功，Console 往往会第一时间把错误扔出来。哪怕错误信息不一定一眼就能彻底解释问题，它至少能告诉你：这是脚本层面的问题，还是别的地方出了偏差。

我通常会先把页面重新触发一遍，再看 Console 里最新出现的报错，而不是盯着旧日志猜。这样能避免被已经修过的历史信息带偏。

Network 决定你是不是还要继续怀疑接口和资源

如果 Console 没有特别直接的错误，下一步就值得去看 Network。脚本没加载、样式 404、接口返回 500、图片请求超时，这些问题都不需要先翻源码，Network 就能先给出答案。

尤其是在前后端分离还没今天这么顺手的年代，很多页面异常其实并不是前端逻辑写错，而是某个资源根本没回来。把请求状态、返回内容、加载顺序先看一遍，排查效率会高很多。

先把问题归到一类，再决定往哪层深挖

我比较喜欢的排查顺序是：

1. 用 Console 确认有没有明显脚本报错
2. 用 Network 确认资源和接口是否正常
3. 再决定要不要去 Elements 或 Sources 深看

这个顺序的好处是，不容易一开始就陷入细枝末节。很多看似复杂的问题，最后只是一个脚本文件路径写错，或者某个接口根本没返回预期数据。

小结

Chrome DevTools 不只是“功能很多”，而是能帮你形成更稳的排查顺序。先看 Console，再看 Network，本质上是在先判断问题属于哪一层。范围一旦收住，后面的调试动作就会轻很多。