第一次在开发者工具里被无限debugger卡住的时候我整个人是懵的——脚本明明没有死循环可只要一打开调试面板代码就稳稳停在debugger那一行怎么点“继续”都没用刚恢复半步又被拽回原地。那种感觉就像一拳打在棉花上使不上劲。无限debugger说白了就是页面在关键代码路径里反复触发debugger语句让调试工具永远处于“中断”状态目的是逼退试图分析页面逻辑的人。它往往和代码压缩、整体混淆绑在一起作为前端反调试的第一道门槛。这篇文章会从它的触发机制讲起把几种常见的绕过思路和可落地的脚本都拆开讲清楚也会分享一些我在实际排查中踩过的坑。适合正在学前端安全、做页面调试时被反调试恶心到的开发者也适合想给自己的页面加反调试保护的工程师读一读至少能理解对手的手法。1. 无限debugger为什么能“卡死”调试器1.1 debugger语句是真“暂停”不是异常有些前端新手会误以为 debugger 是报错其实它是 JavaScript 提供给开发者的“主动暂停指令”。浏览器执行到这一行时只要开发者工具处于打开状态脚本就会立即停在当前位置等待你继续、单步或者查看变量。你可以把它想象成代码里的一个紧急刹车平时不影响运行一旦遇上调试环境就立刻生效。单独一个 debugger 本身没什么威胁最多让你停一次。但它被放进循环或者定时器之后就变成了“无限debugger”每次中断后你刚点击继续下一轮循环马上又触发一次中断调试器永远处于“断点—继续—断点”的空转状态。正因为如此很多人第一反应是“页面卡死了”实际上页面主线程还在运行只是调试器被反复打断无法正常继续。理解了这一点就好理解后面所有绕过方案为什么都围绕“切断触发源”或“改变执行入口”来设计。1.2 无限debugger的三种常见形态我分析过的反调试脚本里无限debugger很少以单一形式出现常见的有三种形态// 形态一死循环中断 (function () { while (true) { debugger; } })(); // 形态二定时器不断触发 setInterval(function () { debugger; }, 100); // 形态三字符串拼接后动态执行 setInterval(function () { const src [deb, gger].join(); new Function(src)(); }, 100);死循环型最简单触发位置固定中断行每次都是同一处定时器型会按固定频率反复中断你清掉一个定时器它可能还会再新建一个动态执行型最麻烦因为源码里根本没有字面量 debugger你直接全局搜索是搜不到的它是运行时通过拼接字符串再交给 Function 构造器执行的静态分析完全看不见。实际平台里这些形态往往会嵌套组合比如外层 setTimeout 定时调度内层再 new Function 动态生成。1.3 直接删代码为什么不是好办法刚开始接触这类问题的人很容易想到“既然 debugger 在源码里那把那一行删掉不就行了”。理论上可行实际操作却经常翻车。原因在于线上脚本通常不是孤立的一行代码而是被压缩、混淆甚至拆成多个模块加载的删除一行后可能会直接导致相关逻辑报错更关键的是很多平台会对脚本内容做签名或完整性校验一旦发现文件内容哈希不一致立刻会拒绝执行或触发另一个错误分支。所以我一直强调一个观念看到无限debugger先别急着“绕过”而是先把它当作一个线索理解这个平台的反调试思路再决定从哪个层面切入。这也是下面两章要展开的内容。2. 从卡死到定位先搞清楚“断在哪、怎么断”2.1 第一次中断后优先看调用堆栈打开开发者工具切到 Sources 面板等待第一次中断。这时不要急着点继续先看一眼右侧的 Call Stack调用堆栈它会把触发 debugger 的那条路径完整列出来从最外层的定时器回调到内部某个函数再到具体是哪一行。通过调用堆栈你能快速判断这个 debugger 是写在哪个脚本文件里是源码直接可见还是来自动态生成的代码。如果是动态生成的代码调用堆栈里通常会出现类似 new Function、eval 之类的标记这时候就算你文件搜不到 debugger 也能确认来源。有时页面会把函数名压缩成 a、b、c 这样的短名那也不怕记下文件和行号接下来可以用格式化按钮把压缩代码还原成可读格式再顺着这个位置往上找它的外层包装函数。2.2 先判断触发类型再选处理方向每种触发形态对应的绕过手段差别很大定位阶段最好先做一个判断。我一般按下表来归类触发类型特征更合适的处理方向死循环型每次中断在同一行频率极高断点方案、本地覆盖定时器型每隔固定时间中断一次清定时器、Hook setInterval动态执行型源码搜不到debugger堆栈有动态标记注入钩子、重写Function事件触发型点击或滚动后才中断事件层面调试判断方法很简单中断后点一下“继续”观察下一个中断发生的时间间隔。如果是瞬间再次中断多半是死循环如果间隔几乎固定则是定时器如果必须执行某个操作才触发那就是事件触发型。这一步判断准了后面能少走很多弯路。2.3 定位阶段的工具建议我推荐在定位阶段优先用浏览器自带的开发者工具尽量不要一开始就上外部工具。自带工具的优点是零成本、跟手而且能看到调用堆栈、作用域、网络请求等完整上下文。等确认了触发来源再考虑用脚本注入、本地覆盖这类更自动化的方式。如果你是在自动化测试环境里比如用无头浏览器跑前端页面那可以借助调试协议在页面加载前做注入或者直接设置全局跳过所有暂停。这类能力适合批量验证多个页面而不是手动一个个点“永不在此暂停”效率差别很大。3. 四种可落地的绕过思路与代码示例3.1 最快上手利用“永不在此暂停”和条件断点如果是源码可见的静态 debugger最简单的办法就是在对应行号上点击右键选择“永不在此暂停”Never pause here。设置后浏览器不会再在该行停下相当于你给这一行单独开了绿灯。还有一种做法是新建条件断点把条件写成 false同样能阻止它触发。这里的关键操作是先让第一次断点停下来确认行号再右键设置不要一上来就盲目右键否则很容易设错位置。这个方案最大的优点就是快几十秒就能解决问题适合 debugger 数量少、位置固定的场景。缺点是它只对当前浏览器配置生效换台机器或者换浏览器就得重新设置如果页面里埋了十几个 debugger手动操作会非常累而且对动态生成的 debugger 完全无效。3.2 更通用在页面加载前注入拦截钩子想要一劳永逸地处理动态生成的无限debugger思路就得改一改不去逐一定位 debugger而是把生成 debugger 的执行入口“顶掉”。字符串拼接型调试代码大多通过 new Function 或 eval 执行所以拦截 Function 构造器是一个很有效的切入点。下面这段脚本可以在页面任何代码执行前注入// 注入到页面上下文的脚本需要保证在目标脚本之前执行 (function () { const originalFunction window.Function; window.Function function (...args) { const src args.join( ); if (/debugger/.test(src)) { return originalFunction.call(this, ); } return originalFunction.call(this, ...args); }; Function.prototype.constructor window.Function; })();这段代码把 window.Function 替换成一个包装函数先检查字符串里有没有 debugger有就直接返回一个空函数没有才走原来的逻辑。同时把 Function.prototype.constructor 也指回包装函数防止页面通过原型链绕回原始构造器。实际使用中要注意重写 Function 是全局性的页面里其它依赖 Function 生成代码的逻辑也可能受影响如果出现报错需要针对性调整。另一个方法是 Hook 定时器在 setTimeout/setInterval 回调层面做过滤类似思路但它更依赖回调函数能被正确识别在混淆代码里效果不稳定。3.3 本地覆盖把目标脚本替换成自己的版本如果静态搜索能看到 debugger 具体写在哪个文件里用浏览器自带的“本地覆盖”功能会更彻底。操作路径是Sources 面板右侧点开 Overrides选择一个本地空目录允许浏览器访问它然后找到包含 debugger 的脚本直接在编辑器里删掉相关逻辑按 CtrlS 保存。之后每次加载页面浏览器都会优先使用本地修改过的文件。这个方案的优点是修改是持久化的不像断点方案那样每次打开都要重新设置缺点是它只能覆盖能被浏览器直接加载的静态资源如果脚本是动态请求、加了签名校验或带了版本号哈希覆盖之后可能被发现。所以我通常把这个方案用在“分析阶段”确认某一处逻辑对整体没有副作用之后再考虑是否用全局注入方案代替。3.4 自动化场景用无头浏览器配合调试协议如果你是做自动化测试或者需要批量分析多个页面手动操作就不现实了。这时可以用无头浏览器配合调试协议在页面加载前注入脚本。举个例子用无头浏览器的 evaluateOnNewDocument 在每一帧文档创建时先运行自定义脚本效果和上面的注入钩子类似const puppeteer require(puppeteer); (async () { const browser await puppeteer.launch({ headless: true }); const page await browser.newPage(); await page.evaluateOnNewDocument(() { const originalFunction window.Function; window.Function function (...args) { const src args.join( ); if (/debugger/.test(src)) { return originalFunction.call(this, ); } return originalFunction.call(this, ...args); }; Function.prototype.constructor window.Function; }); await page.goto(https://your-target-site.com); // 这里继续执行其它自动化逻辑比如截图、断言、提取数据 await browser.close(); })();需要说明的是示例里的地址只是一个占位符实际使用时应该替换成你自己拥有或获得授权测试的站点。无头浏览器方案的优势是可持续集成、可重复执行适合做回归验证缺点是它不保留真实浏览器里的一些交互状态遇到依赖用户行为的反调试机制时不一定能完整覆盖。注意以上所有方案都应该只在你自己拥有或明确授权的项目上使用。反调试技术是前端的合法防御手段绕过它去访问未授权的资源或功能存在明确的法律和合规风险。4. 实际排查中的高频问题与处理记录4.1 一恢复就继续中断清不干净我最早处理这个问题的经历很典型点“继续”之后代码马上又停下就像按了循环播放。排查后发现是定时器型无限debugger——页面用 setInterval 每 100 毫秒触发一次 debugger并且在代码里还设置了随时重建定时器的逻辑。手动点“永不在此暂停”只解决了静态断点对定时器再生成的动态触发无能为力。处理这类问题可以在控制台里先用循环把已知定时器清一遍for (let i 1; i 10000; i) { clearInterval(i); clearTimeout(i); }这样能暴力清掉所有定时器但风险在于页面其它正常逻辑的定时器也会被一起清掉页面可能失去交互能力。所以我通常只把它用于快速验证“是不是定时器引起的中断”验证后再切到注入方案用更精准的方式过滤包含 debugger 的定时器回调。4.2 中断位置随机变化每次都不一样有一种情况特别让人头疼中断点不是固定在一行而是每次跳到不同位置或者过一会儿就换一个文件。这类页面通常是在多个模块里都埋了 debugger并且通过动态加载、混淆压缩把触发点分散开。手动设置断点根本忙不过来。我后来的处理方式是优先启用 Function 钩子先把动态执行型触发全部兜住再配合网络面板确认静态脚本到底加载了哪几个文件把已经确认的静态 debugger 用本地覆盖处理。两件事同时做才能把分散的触发点收拢成已知集合。不要指望一个技巧吃遍所有情况实际平台的反调试往往是组合拳。4.3 修改脚本后页面白屏或直接报错这是最容易被忽视的坑——你辛辛苦苦绕过了无限debugger结果页面直接白屏了根本没法继续分析。原因通常是脚本里有完整性校验服务端下发的内容哈希和本地版本对不上导致校验失败后走了错误分支。另一种可能是修改后的脚本破坏了变量作用域让依赖该变量的其它模块也跟着报错。解决方案分两步先确认是不是作用域问题把修改范围控制在“过滤 debugger”的最小改动上不要顺手改其它逻辑如果是签名校验那就需要用调试器定位校验函数观察它读取的是哪个字段、和什么值比对再把校验结果篡改成预期值。到这里就已经进入更深层的逆向对抗了操作前一定要确认项目是合规可测的。4.4 开发者工具一开就被检测到有些平台会在无限debugger之外额外做一层工具检测表现是你只要打开开发者工具页面就弹警告、自动刷新甚至直接跳转到空白页。常见检测手段包括窗口尺寸差检测和 console 相关方法的 hook。窗口尺寸差检测的原理是开发者工具以独立窗口打开时外层窗口尺寸和当前页面可视区域尺寸会出现差异脚本检测到这种差异就知道有人在调试。应对思路通常是让脚本检测不到这种差异比如把开发者工具窗口拖离页面形成分离窗口或者使用无头浏览器在纯自动化环境里运行让页面根本没有传统意义上的可视化调试窗口。注意这些方法只适合在合规测试环境中验证页面行为不要用于绕过任何访问控制或付费限制技术本身是中立的怎么用才是关键。5. 绕过无限debugger之后下一步学什么5.1 别只学“怎么绕”先理解“为什么会有这层盾”如果你只是为了这次调试绕过无限debugger就算结束了但如果你想真正把前端安全这块吃透建议再往上游想一层平台为什么要费这么大力气做反调试防爬取、防破解、保护核心算法、防止自动化脚本滥用都有可能。理解动机之后你就会知道单纯绕过 debugger 只是万里长征第一步背后还有代码混淆、控制流平坦化、字符串加密、签名校验一整条链路。从另一个角度说无限debugger 也是 JavaScript 运行时特性的一个缩影理解了它你就理解了 debugger 语句、定时器机制、动态执行这些原本零散的知识点是如何在真实系统里组合在一起的。5.2 建议的系统化学习路径如果在本次实践里尝到了逆向分析的乐趣后续可以参考下面这条路径继续深化。先巩固 JavaScript 基础重点理解执行上下文、闭包、作用域链、原型链。再去研究代码压缩和混淆工具的原理明白一个正常模块是怎么变形到不忍直视的。接着学习调试协议理解浏览器和调试器之间是怎么通信的这能帮你从工具使用者变成工具创造者。最后可以找一个自己写的 demo 项目在里面故意埋下几种反调试手段然后自己尝试绕过形成一个“攻—防”闭环。整个过程最适合的环境就是短平快的实验项目而不是冒险去碰别人线上系统。5.3 一定要守住的使用边界最后想认真提醒一句所有调试、绕过、逆向分析手段都应当在“自己拥有或已获授权”的系统上使用。看似技术中立的技巧用在错误场景里就会变成对他人权益的侵害。学习时多练习基础原理工作中多测试自己负责的产品这是对我前面所有经验负责任的唯一方式。我自己的习惯是遇到这类问题先不急着找现成脚本而是花十分钟看一下调用堆栈判断触发类型再决定走哪条路。这样看起来是绕了远路但实际上是在给大脑建立一套分析框架下次再碰到混淆更严重的脚本至少知道该从哪里切入。无限debugger 只是反调试体系里最外围的一环你真正练出来的是“面对未知代码时如何一步步把自己从卡死状态里拽出来”的能力。建议你也找几个自己写的 demo 页面埋上几层反调试亲手绕一遍比看一百篇教程都管用。
