遇到页面开着 DevTools 就疯狂暂停、点几次 Resume 都没用、整个浏览器像被卡住一样这种“无限 debugger”的玩意这几年在不少站点和第三方 SDK 里都见过。Chrome DevTools 的调试机制本身是为开发者服务的但反调试脚本偏偏利用了这一点把调试器变成了拦路虎。本文不聊玄学直接讲我在实战里真正用过的三种绕过思路——DevTools 自带开关、Hook 注入、文件替换以及针对不同变种的具体操作步骤希望能帮你少走点弯路。1. 无限debugger的解剖它靠什么把你“钉死”在调试器里1.1 一条debugger语句为何能反复暂停执行在 JavaScript 里debugger 是一个极其特殊的“语句”。它不是函数、不是关键字声明而是一条运行时会触发调试暂停的指令。只要当前环境存在可用的调试器执行引擎运行到 debugger 这一行就会立刻暂停表现上和你在代码里打了断点一模一样。对做前端开发的人来说这本来是调试利器但在反调试代码里它被用成了“绊马索”。典型实现可能这样setInterval(function() { debugger; }, 100);只要打开 DevTools这条代码每 100 毫秒触发一次暂停你点一次 Resume下一秒又卡住反复循环。真正的“无限 debugger”并不是语法上写了个无限循环而是“你的调试流程永远无法持续”让你连 Console、Network 面板里的信息都来不及看整个分析过程被彻底拖垮。我在给一些第三方项目排查问题时见过更夸张的写法多个定时器叠加、函数递归调用 debugger、甚至通过 eval 动态拼接带 debugger 的字符串。不同写法对应不同的绕过方式后面会逐一拆解。1.2 前端反调试的目的增加摩擦而非绝对安全先说一个容易误解的点。无限 debugger 的目标并不是让代码无法被逆向而是尽可能提高分析成本。它可以挡住普通用户随手打开控制台复制接口数据、查看核心逻辑也可以配合其他检测手段比如定时判断 DevTools 是否打开在检测到调试时跳转空白页或者触发更深的死循环。所以当你面对的不只是“暂停一下”而是一整套“拒绝被调试”的策略时先把心态放平这类防护的本质都是加大摩擦不是绝对安全。理解了这一点后面各种折腾才有方向。1.3 先判断你遇到的无限debugger属于哪类遇到无限 debugger我建议先花两分钟判断类型而不是上来就乱试。根据我遇到的情况大致分为四类类型典型写法特征静态型源码里直接写死一行debugger;最好处理DevTools 自带功能就能解决递归型函数内 debugger 后调用自身暂停位置不断变化容易把 DevTools 卡懵定时器型setInterval(function(){ debugger; }, 100)最常见的“持续攻击”动态型运行时拼接字符串再用 eval 或 new Function 执行最麻烦文件替换容易落空只有搞清楚是哪一类才能选对绕过的第一招。2. 绕过第一式DevTools 自带的断点开关一行代码都不用写2.1 Deactivate breakpoints 按钮全局压制所有断点最快的一招打开 DevTools 的 Sources 面板在顶部工具栏找到一个带斜杠的“禁止符号”图标英文叫 Deactivate breakpoints快捷键 CtrlF8。点击之后所有调试断点暂时失效debugger 语句触发的暂停同样会被忽略。按一下 CtrlF8再点 Resume页面会直接继续执行不再被反复拦截。这是整个绕过流程中成本最低、最不侵入的一招建议第一时间尝试。不过要提醒一句很多人反映“我按了 CtrlF8 还是卡死”。这种情况往往不是断点没禁用而是页面脚本里还有性能极差的死循环或高频 DOM 操作debugger 暂停只是表象真正让 DevTools 卡住的其实是脚本在不断创建新任务。这时候就需要配合下面的禁用 JavaScript 或文件替换手段来处理。2.2 右键 Never pause here定点屏蔽单个debugger如果页面上只有个别 debugger 散落在函数里可以用更精准的方式。在 Sources 面板里找到 debugger 所在的那一行右键选择 Never pause here永不在此暂停。DevTools 会记住这个位置之后脚本执行到这里不会暂停。这个操作只屏蔽当前这一行不影响其他位置的断点。它特别适合那种调试目标时还需要继续观察周边逻辑的场景不会因为全局关断点而失去分析能力。某些第三方库在特定版本里残留了一行调试语句时右键一下就能安静下来继续干活。2.3 两个容易漏掉的辅助功能忽略列表与禁用 JavaScript除了 CtrlF8 和 Never pause hereSources 面板还有两个辅助功能值得记住。一个是 Add script to ignore list。在左侧文件树上右键某个 JS 文件选择 Add script to ignore list调试器 step into 之类的操作会直接跳过这个文件。严格来说它的主要作用是让调试器像对待“黑盒”一样跳过第三方库对单行 debugger 的拦截不是绝对可靠但某些框架或 SDK 里夹带防调试片段时把整个文件加入忽略列表能明显减少干扰。另一个是禁用 JavaScript。在 DevTools 里按 CtrlShiftP输入 Disable JavaScript回车后浏览器会在不刷新页面的情况下停止执行当前页面的所有 JS。这个操作适合只想观察 DOM 结构、网络请求、样式加载等静态信息的时候算是个降维打击的办法。不过要注意禁用 JS 后页面本身的功能逻辑也会失效所以它是临时手段适合用来“静场”之后定位触发点。3. 绕过第二式Hook注入在debugger执行之前把它调包3.1 debugger不是函数为什么还能Hook经常有人问“能不能用 JS 覆盖掉 debugger 这个关键字”答案是不能——debugger 是语言层面的语法指令不属于任何可重写的全局对象。但我们实际说的“Hook debugger”目标并不是去覆盖那个语句而是拦截“生成 debugger 的来源”以及“触发它的调度者”。比如定时器型反调试代码本质是每 100ms 执行一次带 debugger 的函数。只要把这个调度者替换掉问题就解了。这种思维就是 Hook 的核心不跟 debugger 硬碰硬而是把它背后的执行链调包成一个无害版本。3.2 实战Hook掉setInterval和Function构造函数先说覆盖 setInterval / setTimeout 的做法。打开 DevTools 的 Console 面板在页面脚本执行前尽早注入const originalSetInterval window.setInterval; window.setInterval function(fn, delay) { if (fn fn.toString().includes(debugger)) { console.warn([hook] 拦截了setInterval中的debugger调用); return 0; } return originalSetInterval.apply(this, arguments); };这样做的好处是反调试代码即使注册了无数个定时器里面只要包含 debugger 字样全部被拦下来不再触发暂停。console.warn 可以帮你确认拦截行为是否发生调试时还能反推反调试逻辑的触发点。另一类动态型反调试通过 eval 或 new Function 生成代码我们可以覆盖 Function 构造器来过滤const origFn Function.prototype.constructor; Function.prototype.constructor function(...args) { if (args[0] typeof args[0] string args[0].includes(debugger)) { return function() {}; } return origFn.apply(this, args); };原理很简单eval 和 new Function 在执行动态代码时都会经过 Function 构造器这一层我们在这里把包含 debugger 的动态代码替换成空函数相当于在执行入口做了“消音”。3.3 注入时机与恢复现场Hook 最关键的是执行时机。如果页面脚本已经跑完debugger 已经触发了很多次你再去覆盖 setInterval 是改变不了已发生结果的但只要页面里有持续的调度器覆盖后立刻就能生效。我的习惯是这样先打开 DevTools停在 Sources 面板按 CtrlShiftP 执行 Disable JavaScript刷新页面让脚本不执行。然后把面板切到 Console先注入 Hook 代码最后重新启用 JavaScript。这一步操作顺序非常关键很多复杂的反调试场景下它能决定 Hook 是否真正“抢”在反调试代码之前生效。还有一点在 Console 里做的 Hook 只对当前页面环境有效刷新后丢失。如果想长期使用可以把 Hook 脚本存到 DevTools 的 Snippets 里或者直接放进 Sources 的 Overrides 文件里长期生效。另外做 Hook 时不要想着影响面小一点就删掉 console.warn那个日志在排查问题时非常有用。4. 绕过第三式文件替换直接从源码层面移除debugger4.1 配置Local Overrides让浏览器优先加载本地版本文件替换是我处理静态型 debugger 最常用的一招因为它是“源头治理”一劳永逸。Chrome DevTools 自带一个叫 Local Overrides 的功能可以把远端 JS 文件替换成本地修改后的版本。配置方式打开 DevTools → Sources 面板 → 左侧面板顶部切换标签到 Overrides → 点击 Select folder for overrides 选择本地目录允许浏览器访问这个目录。启用后在 Sources 文件树里找到要改的 JS 文件直接编辑内容把 debugger 那一行删掉或注释掉CtrlS 保存。DevTools 会在本地生成一个同名文件刷新页面后浏览器会优先加载这个本地覆盖版本而不是网络文件。如果 JS 是压缩混淆后的单行代码在编辑器里搜索“debugger”删掉debugger;再保存即可。Chrome 会把本地文件当作真实响应来用调试体验完全本地化、可控。4.2 精确定位与正则替换的实操细节压缩混淆后的代码往往是一整行几万字符肉眼找 debugger 非常痛苦。我的经验是先看 Network 面板里实际加载了哪些 JS 文件或者直接在 Console 执行document.scripts列出所有脚本。进入编辑器后 CtrlF 搜索“debugger”基本都能命中再根据上下文判断它属于定时器型还是递归型。如果文件里出现很多处 debugger批量替换的推荐做法是把所有debugger;替换成void 0;。注意不要直接替换成空字符串否则会破坏后面的分号结构或留下语法错误void 0;是一个完全合法且没有副作用的表达式替换后不会影响其他逻辑。提示Local Overrides 是纯文本替换不处理 CSPContent Security Policy里的unsafe-eval之类限制。如果页面有严格 CSP 导致本地覆盖被拦截可能需要配合代理工具。不过实践中大多数站点的静态 JS 资源不会做特别严格的来源校验Overrides 基本可用。4.3 文件替换之外的持久化思路代理工具Local Overrides 虽然方便但也有失效的场景一是 DevTools 没打开时覆盖不生效二是部分站点通过 Service Worker 缓存资源绕过了 DevTools 的覆盖逻辑。这时候可以把方案切换到代理工具比如 Whistle、Fiddler 或 Charles。原理很简单让代理拦截 JS 响应把响应体里的debugger;字符串替换成void 0;再返回给浏览器。浏览器侧看到的仍然是正常域名、正常路径但到手的代码已经被清洗过。这种方式不依赖 DevTools 是否打开也不怕 Service Worker 缓存稳定性最好。代价是需要维护一个代理环境配置成本稍高。5. 变种战场递归、定时器、动态拼接与各种意外情况5.1 递归型debugger先把入口揪出来递归型反调试比较猛常见写法function evil() { debugger; evil(); } evil();这种情况下暂停位置一直在变CtrlF8 有时也会因为执行栈不断变化而让人手忙脚乱。我的处理方式是先用 Deactivate breakpoints 全局关掉断点让页面先跑起来然后打开断点开关再在函数入口位置打一个普通断点等页面停住后用右键 Never pause here 屏蔽掉函数里的 debugger最后恢复执行。一个实用技巧在递归还没来得及触发前先在 Console 里执行window.evil或通过全局对象找到这个函数读取它的源码能直观看到递归结构和自调用的位置。提前搞清楚结构处理起来会从容很多。5.2 定时器型debugger调度者比debugger更容易下手定时器型是最常见的“持续攻击”。除了前面说的 Hook setInterval还有两种做法。第一种在 DevTools 的 Sources 面板里打开 Event Listener Breakpoints勾选 SetTimeout 和 SetInterval 两个事件页面会在定时器回调执行前先停住。这时候你可以看到具体的调度者再决定要不要清除它或者修改它的行为。第二种直接在 Console 里找出定时器的 ID 并清掉clearInterval(intervalId);但要注意有些定时器是嵌套注册的清除一个可能引发其他逻辑报错。不要一上来把所有定时器全清先确认哪个定时器回调里含 debugger再精确处理。5.3 动态拼接型文件替换失效的根源动态拼接型最麻烦。站点在运行时用字符串拼接出带 debugger 的代码再用 eval 或 new Function 执行。你打开 Network 面板看 JS 文件里面根本没有 “debugger” 字样Local Overrides 也就无从下手。还有一种变体字符串本身被编码后拼接搜索 “debugger” 也搜不到。这种场景下前面说的 Function.prototype.constructor Hook 反而更有价值因为它发生在代码执行时不管你动态代码怎么拼最终都要经过构造器这一层我们可以在那里统一过滤。对比一下四种类型的应对策略类型最有效手段文件替换是否可用静态型CtrlF8 / Never pause here可用递归型关闭断点后断入口再局部屏蔽可用定时器型Hook setInterval / 清除定时器可用动态型Hook Function 构造器通常不可用这张表基本就是我排查时的决策依据先看源文件里有没有 debugger 字样有就直接文件替换没有就转用 Hook。遇到混合型就组合使用。6. 综合调试现场复盘一个完整绕过流程的实战记录6.1 一个典型的“卡死”现场某次排查一个第三方数据平台的前端 SDK打开 DevTools 就被钉在某个压缩后的 JS 文件里。按 CtrlF8 后页面能跑了但点击某个功能按钮时又再次卡住。排查下来这个 SDK 里其实混合了多种 debugger 手法。我的处理顺序如下打开 Sources文件树里定位那个 SDK 文件搜索 debugger发现文件里有 3 处静态 debugger另外 1 处被包在new Function里。先用 CtrlF8 全局关闭断点让页面不直接被卡死打开 Network 面板观察关键接口是否正常发出请求。需要分析业务函数时在关键逻辑处打上条件断点设置只在自己关心的数据条件下暂停避免被无关断点打断。对文件里 3 处静态 debugger 用 Local Overrides 全部替换成void 0;。对动态拼接的那 1 处用 Function.prototype.constructor Hook 过滤。刷新验证打开 DevTools 不再卡死业务逻辑也能正常断点调试。这套流程走下来总共耗时不到十分钟。真正的时间主要花在判断 debugger 类型上而不在操作本身。6.2 快速判断该用哪种方案我习惯用一个口诀见静态直接替换见定时器Hook 调度见动态构造器拦截都失灵再考虑代理换文件和禁用 JS。大多数情况下其中一种方案就能解决不一定非要三招齐上。还有一种情况要特别注意debugger 卡死的位置不在业务代码里而是在某个库或者 SDK 内部。这时不要试图去“跑完”它优先用忽略列表和断点开关跳过库代码把注意力放在自己真正要分析的逻辑上。很多人一遇到卡死就慌了结果花大量时间在无关的库代码里打转。6.3 验证绕过是否有效别被假成功骗了绕过之后不能直接说“好了”我一般从三个维度验证页面控制台不再频繁提示 Paused in debugger且能连续执行多步操作不卡住。Network 面板里关键接口能正常请求和返回而不是在加载阶段就被拦截。在 Sources 面板里手动设置普通断点确认断点仍然能触发。如果连普通断点都失效了说明刚才可能把整个断点机制也关掉了需要重新调整。这三点都通过才算真正绕过而不是暂时跳过了某一个 debugger。7. 边界与习惯调试别人的代码时这几条要注意聊到这儿我必须认真说一段因为网上类似的教程太多了初学者绕过一个 debugger 就到处去破解商业站点这是容易踩出问题的地方。无限 debugger 多数出现在商业站点、在线服务或一些加密 SDK 里它的存在是站点作者的一种自保手段。学习绕过技巧首先应该用于调试自己项目里引入的第三方依赖比如某个 JS 库总是弹 debugger 导致本地开发效率低下或者想分析某个开源项目里故意保留的调试陷阱。这些场景合理合法不影响别人服务。但如果你拿这套技巧去抓别人付费接口、绕过登录校验、盗取数据那已经不是技术问题了而是合规与法律问题。我的原则是只在自己有权访问、有权分析的目标上使用这些手段并且不用来做破坏性操作。从实操习惯来说还有几点经验想分享。第一平时调试第三方库时优先用 CtrlF8 和 Never pause here尽可能少用 Hook 和文件替换避免把线上环境改得面目全非。第二涉及文件替换时记得在本地目录留好备份因为 Local Overrides 是直接覆盖本地文件的改错了会影响后续调试。第三Hook 脚本里最好带日志输出能帮你确认拦截时机理清调用链也会让你更清楚 debugger 是在哪个环节被触发的——毕竟绕过只是手段搞清楚触发机制才是这次调试里最有价值的收获。用这套思路处理了太多类似问题之后我的体会是无限 debugger 这类反调试手段大多数时候并不是真的牢不可破它更像是筛选器筛掉一拨不愿意动脑筋的人。真正吃透 DevTools 的调试机制、Hook 原理和文件替换思路之后再看到这种代码心态反而很平静——它只是代码里的一行语句而我们要做的只是妥善地绕开它继续本该完成的调试工作。