使用条件断点进行更好的调试
我喜欢有条件的断点 。 真！ 它们是我最喜欢的调试工具。
当我开始进行Web开发时，对我来说，“调试”是指创建一个<pre id='log'></pre>并将字符串附加到其内容以充当日志。 但是，一旦Firebug出现 ，然后当浏览器开始使用自己的开发工具进行烘焙时，就像从滑板升级到私人飞机一样。 断点，监视，调用堆栈，事件探查器，网络活动监视器—它们都很有用，我也不想丢掉它们。
但是有条件的断点是我的最爱，而且还差得远。 这是我的使用方式：
仅在某些情况下破裂
显而易见的情况是到处都有记录：创建一个断点，仅在特定表达式的值为true时才暂停执行。
当我试图跟踪经常运行的一段代码中的某些奇怪行为时，这种方式使用条件断点是很好的选择，但是该行为只有在存在特定数据组合时才会被破坏。 普通断点每次都会暂停执行，调试会很繁琐，但条件断点仅允许您在存在正确数据时暂停，因此您可以停下来环顾四周。 真好
但这就是平凡的用法。 老实说，这可能是我使用它们的最不常用的方式。 您知道，条件断点是一把手术刀 。 他们是猴子修补者的梦想。
将变量导出到全局范围
您是否曾经想过通过控制台访问函数中本地定义的变量，但又从函数外部的执行上下文中访问控制台？ 这一直在我身上发生； 我想让我的应用程序加载并运行到空闲状态，然后能够检查锁定在闭包中的某些对象的属性或方法。 有条件的断点可以解救！
这里的主要技巧是使用低逗号运算符 ，以确保该赋值不会评估为真，因为这会导致断点暂停执行。 取而代之的是，断点表达式的计算结果为false ，应用程序将一直通过它并一直运行直到空闲，然后您可以通过键入控制台名称来检查控制台中与您内心内容有关的值。
注意：我习惯于做window.varName而不是varName所以我不会意外地修改相对于断点位置存在于外部作用域中的变量。
提示：在启用了ES2015 +的浏览器中，使用简写属性名称快速导出一系列变量： window.dealyBob = {var1, var2, otherVar}, false
使用逗号操作这种方式的关键是使条件断点唱歌 。
在不编辑代码的情况下添加日志
有条件断点的最常见用例是日志记录。 我知道专业开发人员在console.log驱动的开发中取乐是很普遍的，但是能够无需重新构建甚至不重新加载就能检测代码，实时观察所有运行情况，并获得详细的诊断输出，这真是太棒了。
这样做的奇妙之处在于，开发工具将保存断点与相关文件的关联（至少在Chrome中，这些天我通常最常在其中工作），因此下次我仍在使用它们在另一个会话中加载该应用程序，而无需我真正保存对我的应用程序代码的任何更改！ 这给了我一种纯粹面向浏览器的运行时面向方面的日志记录系统。 如何分离关注点？
修改资料
假设您有一个错误，即复制要加载特定的数据组合，并且要达到该状态，您首先需要执行许多繁琐的步骤。 不再！ 作为一个敏锐的读者，我相信您之前已经注意到，如果您可以修改window属性以在条件断点表达式中创建新的全局变量，那么没有什么可以阻止您修改其他任何内容。
因此，继续将一堆JSON粘贴到条件断点中，并将其分配给所需的任何变量。 繁荣！ 告别繁琐的repro。
提示：逗号运算符使您可以将两个以上的语句链接在一起，因此，如果要进行一整套分配，请继续说： (var1 = x; var2 = y; var3 = z), console.log('overriding with', x, y, z), false
相关的Protip：不要忘记您可以从控制台在任何全局对象上设置值。 如果您有特别大的对象用作替代，或者想要更改条件断点而无需修改实际断点的数据，则将您带到控制台并说出window.bigOverrideObject = {pasteYourObjectHere} ，然后在条件断点表达式， var1 = window.bigOverrideObject, false
注入和测试新代码
您是有见识的读者，您可能已经意识到条件断点表达式只是在放置它们的作用域和上下文中运行JavaScript代码。 如果您可以在条件断点处进行分配或写入控制台，为什么不使用它来测试新的应用程序代码？ 是的
在您喜欢的任何位置插入条件断点，然后运行所需的任何内容！ 有一些局限性，例如，你不能return从当前函数直接在断点表达，但在大多数情况下，你可以做任何转换或计算你的应用需求。
这就是猴子修补方面的来龙去脉：您可以结合所有这些技术，并使用条件断点来覆盖整个函数，即使它们位于闭包内部也是如此。 核实：
姐姐，很偷偷摸摸！ （警告：'80年代孩子参考）
Protip：您的开发工具显然不会修改已部署的应用程序代码，因此这是一种在不进行整个构建/部署周期的情况下尝试在生产系统中进行操作的好方法。 请注意，不要以使它们最终破坏您的生产数据的方式进行调整！
结论
我喜欢条件断点。 现在我希望你也这样做！
PS：特别感谢我的朋友和有条件断点爱好者Brian Sinclair对本文的审阅以及对这篇文章的启发。 他对条件断点的热爱确实是无条件的 。
关于Revin Guillen
Revin是一位长期的Web开发人员，自90年代中期以来就一直在编写JavaScript应用程序，并在小公司，Large Enterprises™中以雇员身份并以咨询为基础工作。 他看过很多东西。
翻译自: https://davidwalsh.name/debugging-conditional-breakpoints