5 个 Browser DevTools 技巧，让我的调试时间减半
Source: Dev.to
停止猜测和盲目调试，改为系统化的 Bug 重现
强迫自己在做任何改动前先稳定地重现 Bug
大多数开发者会陷入“猜测调试”的陷阱——在没有先弄清问题的情况下随意修改代码。 在动任何代码之前，先复现触发 Bug 的完整场景。 收集截图、服务器日志、设备信息以及环境设置。 列出导致问题的每一步，并确保你运行的版本与报告 Bug 时的版本一致。
回答三个关键问题：
- 你能重现它吗？
- 它从哪里开始？
- 你追踪到了数据流吗？
如果无法重现 Bug，要么是信息不足，要么是 Bug 真正间歇性出现。 要彻底记录所有细节，并考虑外部因素，如集成问题或网络不稳定。 对于不可重现的 Bug，尝试用异常数据输入模拟边缘情况，并添加详细日志以备后续出现时使用。 理解为何无法重现 Bug 本身就能提供有价值的洞见。
避免情绪化调试和随意代码修改
“在我的机器上可以工作”这句话往往意味着没有系统化地重现 Bug。 在重现尝试过程中清除缓存和 Cookie，且在弄清根本原因之前不要轻易改动代码。 如果 Bug 看似关键却始终难以捕捉，继续在重现的过程中诊断。 监控模式并关联可能揭示触发因素的问题，但绝不要让沮丧驱动随意的修复。
采用五步框架加速 Bug 解决
A. 每次都可靠地重现 Bug
创建一个受控环境，使问题能够一致地复现。 记录触发 Bug 的精确条件、用户操作和环境变量。
B. 确定是组件、API、数据还是副作用导致
使用“二分查找”策略：系统性地缩小问题范围，判断是 UI 组件、API 调用、数据损坏，还是意外的副作用导致。 每一次检查都能将问题空间减半。
C. 在修改代码前，用 DevTools 和断点检查
不要立即编辑代码，而是在 Chrome DevTools 中放置有针对性的断点。 列出你的假设，然后通过逐步执行并观察实际值来验证这些假设。
D. 做最小化的修复
实现解决已识别问题所需的最小改动。 精细的修复可以防止引入新 Bug，保持代码库的稳定。
E. 验证解决方案在多种状态下均有效
在不同场景和应用状态下测试修复。 这确保解决方案针对根本原因，而不是仅仅治标。
打破对 console.log 的依赖，提升 DevTools 使用技巧
使用断点代替到处散布 console.log 语句
断点会在特定位置暂停执行，让你在不在代码中留下日志语句的情况下检查变量值。
DevTools 提供多种断点类型：
- 行断点 – 在确切的代码位置暂停。
- 条件断点 – 仅在满足条件时触发。
- 事件监听断点 – 当事件（例如点击）触发时暂停。
- DOM 断点 – 当元素发生变化时停止。
- XHR/fetch 断点 – 捕获网络请求。
- 异常断点 – 在未捕获的错误处停止。
系统化地单步执行代码，观察数据流动
设置断点后，使用 DevTools 的单步控制逐行执行代码。 “Step into next function call”（进入下一函数调用）命令让你深入更深的调用栈，而 “Step over”（跳过）则跳过已经验证的函数。 这种系统化的方法可以揭示数据在应用中的流动方式，帮助定位出错的具体位置。