本地网页js调试工具
Chrome的本地F12开发者工具是我每天打开频率最高的面板，没有之一。网页但直到上个月帮朋友排查一个线上bug，调试我才意识到自己过去对它的工具使用方式有多粗糙。那个问题其实很简单——某个按钮点击后没有反应，本地console里报了个错，网页我第一反应是调试打断点。
结果呢？工具我花了十分钟在Sources面板里翻找那个压缩过的bundle文件，眼睛都快看花了。本地朋友在旁边说了一句：“你为什么不试试直接在Console里跑一下那个函数？网页”我愣住了。对啊，调试我完全可以直接在Console里调用那个全局函数，工具看看它返回什么，本地再决定下一步。网页
这个经历让我重新审视了本地调试这件事。调试所谓“本地网页js调试工具”，核心其实不是工具本身，而是你怎么用它。Console不只是看报错的地方，它是个交互式环境。你可以直接输入变量名查看当前值，可以手动触发某个事件，甚至可以临时修改页面上的数据。这些操作不需要刷新页面，不需要重新编译，改完立即生效。
我自己的习惯是，先打开Console看看有没有红色报错，但别急着修。先看看错误信息旁边的堆栈跟踪，点进去能直接跳到出错的源文件位置。如果代码是压缩过的，Chrome会自动还原变量名，这功能叫pretty print，在Sources面板左下角有个花括号图标，点一下就行。
调试逻辑问题的时候，我最常用的不是断点，而是条件断点。右键点击行号，选择“Add conditional breakpoint”，输入一个条件表达式，比如item.id === 123。这样只有当符合条件的代码执行到这一行时才会停住，省去了大量手动跳过无关循环的时间。
还有一个容易被忽略的功能是Network面板里的“Block request URL”。有时候页面加载了某个外部脚本，导致本地调试时行为异常，你可以在Network里右键那个请求，选择Block，然后刷新页面。这比去改代码或者禁用整个插件要快得多。
当然，工具再好用也有局限。当你调试的是异步逻辑，比如setTimeout或者Promise链，断点经常会在错误的时间触发。这时候我会在Console里手动输入setTimeout(() => { console.log('step1') }, 1000)来模拟时序，或者直接在代码里临时加几个console.log，输出带标记的中间值。虽然看起来原始，但实际效果往往比调试器更直接。
最后说一个我个人的小技巧。在Elements面板里选中一个DOM节点，然后在Console里输入$0，就能直接拿到这个节点的引用。配合$0.style.color = 'red'这样的操作，你可以不刷新页面就验证样式修改。这个功能我用了三年才发现，当时有种相见恨晚的感觉。
本地调试的本质是快速试错。工具提供的所有面板、快捷键、断点类型，都是为了缩短你从发现问题到理解问题的时间。别被工具的功能列表吓到，用你需要的，忽略其余的。下次打开F12的时候，试着在Console里输入一个你正在调试的变量名，看看输出，可能比你在代码里翻半天更有效。