由于web前端项目的特殊性，所有的前端代码基本上是开源的，这就意味着，访问者可以无条件的查看所有的代码，甚至进行调试，弄清项目的业务逻辑，这样，漏洞挖掘者就可以很方便的找出网站的漏洞进行攻击。
出于安全的目的，前端会对代码进行各种压缩打包，混淆等，增加阅读代码的难度，但对于调试，似乎很多人并没有引起应有的重视，下面会介绍一种比较基础的方法，用于阻止网站访问者对项目进行调试。
在js代码中加入debuger之后，网站打开开发者模式之后就会在debuger的地方触发断点进行调试，而如果不是出于调试模式下，debugger则会被忽略，利用浏览器的这个特性，我们可以编写一下这行代码：
(function noDebuger(){function testDebuger(){var d=new Date();debugger;if(new Date()-d>10){alert('大佬，手下留情…');return true}return false}function start(){while(testDebuger()){testDebuger()}}if(!testDebuger()){window.onblur=function(){setTimeout(function(){start()},500)}}else{start()}})();我们编写了一个匿名函数并自执行，在testDebuger方法中，我们在debuger前后分别获取了两个时间，并对比这两个时间差，如果debugger之前前后的时间差超过了10毫秒，我们就判定当前用户打开了开发者工具，这个时候我们就可以执行一些反制措施，然后返回检测状态。对于start函数，我们写死了一个循环，当我们检测到用户打开了调试，则会不断的去执行testDebuger，这个时候代码就会不断的命中断点，导致访问者无法调试。
那么接下来，就是何时执行start函数的问题了，理论上我们可以进入网站时就直接执行start函数，但这样会在项目中无限执行testDebuger，这样对性能消耗太大，站在性能优化的角度上，我们在后面的代码做了一些优化，一开始我们只执行一次testDebuger，当检测不到调试时，我们给onblur事件添加一个方法，只有当页面onblur时，我们就会开始执行start，这样，用户一旦打开了开发者工具，则必然触发onblur，这个时候反调试功能触发，而如果一开始就检测到了调试模式，那么就是用户已经开好开发者工具等着调试了，这个时候直接执行start，就无所谓了。这样，就能在不影响性能的情况下，达到反调试的目的。
