突破前端反调试--阻止页面不断debugger

原文地址： https://segmentfault.com/a/11...
其实我也不太确定是不是反调试，但是他阻止我看他代码了，那就是反调试，姑且这么称呼吧。

问题复现

一次扒某网站的前端代码，打开控制台要看Network，结果发现他们页面一打开控制台就不断的debugger，100ms一次，很影响看页面内容。就像下面这样的

问题分析

每次在断点处停下来的时候页面都会跳到source这个tab页面，也能够看到他的debugger的代码，其实他的实现很简单，只有这一行代码

(function() {var a = new Date(); debugger; return new Date() - a > 100;}())

虽然简单，但是却很有效。

• 不停地打断你，页面跳到source页面，阻止你看他代码不
• 断的产生不可回收的对象，占据你的内存，造成内存泄漏，没过多久浏览器就会卡顿

所以他带来的影响还是挺大的，我们需要解决这个问题。

问题解决

这个问题解决起来还是蛮简单的，问题解决只需要一句话：禁止断点。
而对应的操作是在Chrome控制台的Source Tab页点击Deactivate breakpoints按钮或者按下Ctrl + f8(下图)。

这样就能禁用断点了，问题就得到了解决，但是当你需要调试的时候记得要起他哦。很简单的操作，但是你如果对Chrome控制台调试不熟悉的话还是比较头疼的。在这里记录一下，分享给更多的人。

更新

2018-09-10更新

后来发现这种做法有时候有些不妥，就比如有我们看别人网站代码有时候就是为了调试网站的代码，那么这时我们这么直接干脆的禁止断点后我们也没办法调试网站的代码了，那这就有点杀敌一千自损八百的意思。那有什么办法可以满足我们既能阻止网站一直debugger还能让我们继续调试网站的代码呢？这就要看网站怎么实现不断debugger了:
有的网站做的比较简单，是用具名函数做的，类似这样

setInterval(startDebug, 100); // 举个例子而已，很多网站并不是这么实现的
function startDebug() { debugger; };

这种情况比较好解决，我们随便重新定义这个方法就行了，形如:

function startDebug() {};

但是也有的网站做的比较厉害点，用匿名函数来实现，形如:

setInterval(function () { debugger }, 100); // 举个例子而已，很多网站并不是这么实现的

这种情况就比较蛋疼了，目前我是没啥解决方法，如果有人知道的话，不妨在下面留言了。

2019-03-13更新

下面有位老兄(@XYShaoKang)提到用条件断点来应对这样的实现

setInterval(function () { debugger }, 100); // 举个例子而已，很多网站并不是这么实现的

我试了下，确实可以，但是有局限性。
先说可以应对的情况，一个动图说明问题。

再来说说不能应对的情况，还是一个动图说明问题。

也就是说，条件端点的适用情况与具体代码的书写风格有关系。
另外，我发现Add conditional breakpoint下面的Never pause here也能在突破反调试的时候也能起到一定作用。局限性与上Add conditional breakpoint一样。
同样用两个动图说明问题。

能work的情况

不能work的情况