遇到页面开着 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，快捷键 Ctrl+F8。点击之后，所有调试断点暂时失效，debugger 语句触发的暂停同样会被忽略。
按一下 Ctrl+F8，再点 Resume，页面会直接继续执行，不再被反复拦截。这是整个绕过流程中成本最低、最不侵入的一招，建议第一时间尝试。
不过要提醒一句：很多人反映“我按了 Ctrl+F8 还是卡死”。这种情况往往不是断点没禁用，而是页面脚本里还有性能极差的死循环或高频 DOM 操作，debugger 暂停只是表象，真正让 DevTools 卡住的其实是脚本在不断创建新任务。这时候就需要配合下面的禁用 JavaScript 或文件替换手段来处理。
2.2 右键 Never pause here：定点屏蔽单个debugger
如果页面上只有个别 debugger 散落在函数里，可以用更精准的方式。在 Sources 面板里找到 debugger 所在的那一行，右键，选择 Never pause here（永不在此暂停）。DevTools 会记住这个位置，之后脚本执行到这里不会暂停。
这个操作只屏蔽当前这一行，不影响其他位置的断点。它特别适合那种调试目标时还需要继续观察周边逻辑的场景，不会因为全局关断点而失去分析能力。某些第三方库在特定版本里残留了一行调试语句时，右键一下就能安静下来继续干活。
2.3 两个容易漏掉的辅助功能：忽略列表与禁用 JavaScript
除了 Ctrl+F8 和 Never pause here，Sources 面板还有两个辅助功能值得记住。
一个是 Add script to ignore list。在左侧文件树上右键某个 JS 文件，选择 Add script to ignore list，调试器 step into 之类的操作会直接跳过这个文件。严格来说，它的主要作用是让调试器像对待“黑盒”一样跳过第三方库，对单行 debugger 的拦截不是绝对可靠，但某些框架或 SDK 里夹带防调试片段时，把整个文件加入忽略列表能明显减少干扰。
另一个是禁用 JavaScript。在 DevTools 里按 Ctrl+Shift+P，输入 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 面板，按 Ctrl+Shift+P 执行 Disable JavaScript，刷新页面让脚本不执行。然后把面板切到 Console，先注入 Hook 代码，最后重新启用 JavaScript。这一步操作顺序非常关键，很多复杂的反调试场景下，它能决定 Hook 是否真正“抢”在反调试代码之前生效。
还有一点：在 Console 里做的 Hook 只对当前页面环境有效，刷新后丢失。如果想长期使用，可以把 Hook 脚本存到 DevTools 的 Snippets 里，或者直接放进 Sources 的 Overrides 文件里长期生效。另外，做 Hook 时不要想着影响面小一点就删掉 console.warn，那个日志在排查问题时非常有用。
4. 绕过第三式：文件替换，直接从源码层面移除debugger
4.1 配置Local Overrides，让浏览器优先加载本地版本
文件替换是我处理静态型 debugger 最常用的一招，因为它是“源头治理”，一劳永逸。Chrome DevTools 自带一个叫 Local Overrides 的功能，可以把远端 JS 文件替换成本地修改后的版本。配置方式：
打开 DevTools → Sources 面板 → 左侧面板顶部切换标签到 Overrides → 点击 Select folder for overrides 选择本地目录，允许浏览器访问这个目录。启用后，在 Sources 文件树里找到要改的 JS 文件，直接编辑内容，把 debugger 那一行删掉或注释掉，Ctrl+S 保存。DevTools 会在本地生成一个同名文件，刷新页面后，浏览器会优先加载这个本地覆盖版本，而不是网络文件。
如果 JS 是压缩混淆后的单行代码，在编辑器里搜索“debugger”，删掉debugger;再保存即可。Chrome 会把本地文件当作真实响应来用，调试体验完全本地化、可控。
4.2 精确定位与正则替换的实操细节
压缩混淆后的代码往往是一整行几万字符，肉眼找 debugger 非常痛苦。我的经验是先看 Network 面板里实际加载了哪些 JS 文件，或者直接在 Console 执行document.scripts列出所有脚本。进入编辑器后 Ctrl+F 搜索“debugger”，基本都能命中，再根据上下文判断它属于定时器型还是递归型。
如果文件里出现很多处 debugger，批量替换的推荐做法是：把所有debugger;替换成void 0;。注意，不要直接替换成空字符串，否则会破坏后面的分号结构或留下语法错误；void 0;是一个完全合法且没有副作用的表达式，替换后不会影响其他逻辑。
提示：Local Overrides 是纯文本替换，不处理 CSP（Content 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();这种情况下暂停位置一直在变，Ctrl+F8 有时也会因为执行栈不断变化而让人手忙脚乱。我的处理方式是：先用 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 反而更有价值，因为它发生在代码执行时，不管你动态代码怎么拼，最终都要经过构造器这一层，我们可以在那里统一过滤。
对比一下四种类型的应对策略：
| 类型 | 最有效手段 | 文件替换是否可用 |
|---|---|---|
| 静态型 | Ctrl+F8 / Never pause here | 可用 |
| 递归型 | 关闭断点后断入口，再局部屏蔽 | 可用 |
| 定时器型 | Hook setInterval / 清除定时器 | 可用 |
| 动态型 | Hook Function 构造器 | 通常不可用 |
这张表基本就是我排查时的决策依据：先看源文件里有没有 debugger 字样，有就直接文件替换；没有，就转用 Hook。遇到混合型就组合使用。
6. 综合调试现场复盘：一个完整绕过流程的实战记录
6.1 一个典型的“卡死”现场
某次排查一个第三方数据平台的前端 SDK，打开 DevTools 就被钉在某个压缩后的 JS 文件里。按 Ctrl+F8 后页面能跑了，但点击某个功能按钮时又再次卡住。排查下来，这个 SDK 里其实混合了多种 debugger 手法。
我的处理顺序如下：
- 打开 Sources，文件树里定位那个 SDK 文件，搜索 debugger，发现文件里有 3 处静态 debugger，另外 1 处被包在
new Function里。 - 先用 Ctrl+F8 全局关闭断点，让页面不直接被卡死；打开 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 导致本地开发效率低下，或者想分析某个开源项目里故意保留的调试陷阱。这些场景合理合法，不影响别人服务。
但如果你拿这套技巧去抓别人付费接口、绕过登录校验、盗取数据，那已经不是技术问题了，而是合规与法律问题。我的原则是：只在自己有权访问、有权分析的目标上使用这些手段，并且不用来做破坏性操作。
从实操习惯来说，还有几点经验想分享。第一，平时调试第三方库时，优先用 Ctrl+F8 和 Never pause here，尽可能少用 Hook 和文件替换，避免把线上环境改得面目全非。第二，涉及文件替换时，记得在本地目录留好备份，因为 Local Overrides 是直接覆盖本地文件的，改错了会影响后续调试。第三，Hook 脚本里最好带日志输出，能帮你确认拦截时机，理清调用链，也会让你更清楚 debugger 是在哪个环节被触发的——毕竟绕过只是手段，搞清楚触发机制，才是这次调试里最有价值的收获。
用这套思路处理了太多类似问题之后，我的体会是：无限 debugger 这类反调试手段，大多数时候并不是真的牢不可破，它更像是筛选器，筛掉一拨不愿意动脑筋的人。真正吃透 DevTools 的调试机制、Hook 原理和文件替换思路之后，再看到这种代码，心态反而很平静——它只是代码里的一行语句，而我们要做的，只是妥善地绕开它，继续本该完成的调试工作。
