爬虫实战：绕过无限debugger的4种浏览器方案与2种编程方法

1. 项目概述：当爬虫遇上无限debugger

做爬虫开发的朋友，估计都遇到过这种让人血压飙升的场景：你打开F12开发者工具，正准备分析页面结构、抓取网络请求，结果页面一加载，浏览器就“咔”一下自动跳转到Sources（源代码）标签页，光标停在一个debugger;语句上，整个脚本执行被强行暂停。你手动点一下继续运行，不到一秒，又跳回来了，陷入一个无限循环。这就是前端常用的反爬手段之一——无限debugger。它的目的很明确，就是干扰和阻止你使用浏览器开发者工具进行正常的调试与分析，从而增加你编写爬虫代码的难度。

这招对于依赖动态渲染数据的现代网站（尤其是涉及核心业务数据的后台、金融、社交平台等）来说非常常见。它不直接阻止你访问，而是给你制造麻烦，让你无法顺畅地查看XHR/Fetch请求、分析JavaScript执行逻辑、或者直接复制出生成某个关键参数（如token,sign）的代码。作为爬虫工程师，绕过它就成了必须掌握的技能。今天，我们就来深入拆解无限debugger的原理，并分享几种经过实战检验的绕过方案，从浏览器的简单设置到编程式的自动化处理，让你下次再遇到时能从容应对。

2. 无限debugger的实现原理与核心思路

要绕过它，首先得明白它是怎么工作的。无限debugger本身并不是什么高深的技术，它纯粹是利用了浏览器开发者工具的调试协议特性。

2.1 常见的实现方式

最常见的方式是在JavaScript代码中插入一个无限循环的debugger语句，或者监听开发者工具的打开事件。

方式一：直接的无限循环debugger

setInterval(function(){ debugger; }, 100);

这段代码会每隔100毫秒执行一次debugger;语句，只要开发者工具是打开状态，就会不断触发断点暂停。

方式二：结合Function构造器这是一种更隐蔽的方式，通过Function构造器将debugger代码转换成字符串，增加检测和格式化代码的难度。

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

或者更复杂的，通过检测代码执行时间差来判断是否在调试状态。

方式三：监听开发者工具事件有些网站会尝试检测开发者工具是否被打开。虽然现代浏览器出于隐私考虑限制了精确检测，但一些基于窗口大小、调试器是否附加的间接检测方法仍被使用。

2.2 反爬方的核心逻辑

部署无限debugger的反爬方，其核心逻辑不在于“防住”你，而在于“恶心”你，提高你的技术成本。他们的预期是：

1. 阻断自动化：让基于Puppeteer、Selenium等自动化工具的无头浏览器（headless browser）直接卡死，因为无头模式通常也会启用调试协议。
2. 干扰手动分析：让逆向工程师在手动分析关键算法时频繁被打断，降低效率，增加出错概率。
3. 筛选对手：过滤掉一部分技术能力不足或耐心不够的爬虫开发者。

理解了这一点，我们的绕过思路也就清晰了：核心目标是让debugger;语句失效，或者让浏览器忽略它，而不是去删除或修改网站的源代码。

3. 浏览器开发者工具内的绕过方案

对于手动分析或编写爬虫原型阶段，直接在浏览器里解决问题是最快的。这里有几个层层递进的技巧。

3.1 方案一：条件断点（最常用、最有效）

这是我最推荐的手动处理方法，几乎能应对90%的简单无限debugger。

1. 当浏览器在debugger;处暂停时，在Sources面板右侧的Breakpoints（断点）区域，找到对应的断点。
2. 右键点击该断点，选择“Edit breakpoint...”。
3. 在弹出的输入框中，输入条件false。这意味着“只有当条件为真时才中断”，而false永远不为真。
4. 按下回车保存，然后点击继续运行按钮（F8）。你会发现，世界清净了，debugger语句不再起作用。

原理：我们给这个特定的debugger断点附加了一个永不成立的条件，浏览器调试器在每次执行到这行时都会评估条件，结果为false，因此不会触发暂停。

注意事项：

• 这个方法只对当前这个具体的debugger;语句断点有效。如果网页中有多个不同位置的debugger，你需要找到每一个并如法炮制。
• 刷新页面后，断点设置会丢失，需要重新操作。适合单次分析会话。

3.2 方案二：禁用所有断点（全局开关）

如果你不确定debugger藏在哪，或者它被动态生成，可以使用这个全局开关。

1. 在Sources面板，找到并点击那个像暂停符号中间有个斜杠的图标（Deactivate breakpoints）。
2. 点击后，图标会变成蓝色。此时，所有断点（包括你手动添加的和代码中的debugger）都会被禁用。
3. 刷新页面，页面将无视任何debugger语句正常加载。

实操心得：这个方法非常暴力有效，但有一个致命缺点：你自己也无法再使用任何断点进行调试了。所以它适用于你只需要查看网络请求或元素，而不需要调试JS逻辑的场景。用完记得关掉，否则你后续自己调试时会发现断点全失灵了。

3.3 方案三：Overrides本地代码覆盖（一劳永逸）

这是更高级、更持久的方法，适合需要反复分析同一个页面的情况。它的原理是允许你将线上网站的JavaScript文件映射到本地一个修改过的副本。

1. 在Sources面板，找到左侧的Overrides选项卡，点击Select folder for overrides，选择一个本地空文件夹（例如debugger_override），并授权浏览器访问。
2. 在Page标签下找到包含debugger;的JS文件（通常在类似www.example.com/static/js/main.xxxx.js的路径下）。
3. 右键点击该文件，选择Save for overrides。浏览器会在你刚选择的文件夹中创建该文件的本地副本。
4. 在本地副本中，搜索debugger关键字，找到后直接将其删除，或者替换为// debugger;（注释掉）。
5. 关键步骤：按Ctrl+S保存这个本地文件。
6. 刷新页面。你会发现浏览器加载的是你修改过的本地JS文件，其中的debugger已经失效了。浏览器地址栏右侧会出现一个紫色的覆盖图标。

注意：Overrides功能需要确保开发者工具在刷新页面时保持打开状态。修改文件后务必保存，刷新才能生效。这个方法可以永久性“修补”当前站点的这个JS文件，直到你清除覆盖或文件版本更新。

3.4 方案四：忽略脚本（忽略整个文件）

如果debugger存在于一个你不关心的、第三方或无关紧要的脚本文件中，你可以直接让调试器忽略整个文件的执行。

1. 在包含debugger的脚本文件上右键。
2. 选择“Add script to ignore list”。
3. 之后，这个文件中的代码将不会在调试器中显示，其中的断点也不会生效。

适用场景：这个功能主要用于屏蔽那些压缩过的、难以阅读的库文件（如vendor.xx.js），如果debugger恰好只存在于这类文件中，用这个方法很便捷。但如果debugger在核心业务逻辑文件里，忽略该文件会导致你无法调试其他重要代码。

4. 编程式自动化绕过方案

当我们需要将爬虫投入生产环境，进行自动化数据采集时，手动操作浏览器的方法就不适用了。我们需要在代码层面解决问题。这里以最常用的Puppeteer（Node.js）和Selenium（Python）为例。

4.1 Puppeteer (Node.js) 方案

Puppeteer提供了强大的CDP（Chrome DevTools Protocol）协议控制能力，绕过debugger主要有两种思路。

思路一：在页面加载前注入代码，重写或禁用debugger这是最彻底的方法。我们在页面任何JavaScript执行之前，就向页面注入一段脚本，将全局的debugger关键字“废掉”。

const puppeteer = require('puppeteer'); (async () => { const browser = await puppeteer.launch({ headless: false }); // 非无头模式便于观察 const page = await browser.newPage(); // 关键步骤：在页面加载前，注入脚本覆盖debugger功能 await page.evaluateOnNewDocument(() => { // 方法1：将debugger重写为一个空函数 window.debugger = function() {}; // 方法2：更暴力，直接删除Function.prototype.constructor的debugger调用（谨慎使用） // Object.defineProperty(Function.prototype, 'constructor', { // value: function(...args) { // if (args && args.length > 0 && args[0].includes('debugger')) { // return function(){}; // } // return originalConstructor.apply(this, args); // } // }); }); // 也可以监听CDP的Debugger.paused事件，并在发生时自动继续 const client = await page.target().createCDPSession(); await client.send('Debugger.enable'); await client.send('Debugger.setPauseOnExceptions', { state: 'none' }); client.on('Debugger.paused', (pauseEvent) => { console.log('Debugger paused, auto-resuming...'); client.send('Debugger.resume'); }); await page.goto('https://目标网站.com'); // ... 你的后续爬取逻辑 await browser.close(); })();

参数计算与选择过程：evaluateOnNewDocument方法会在页面文档创建后、任何脚本执行前运行我们的代码，确保了优先级。使用window.debugger = function() {}是最简单安全的，它只覆盖了全局的debugger语句调用。更复杂的方法可能涉及修改原型链，但需小心引发其他副作用。

思路二：通过CDP协议忽略所有断点直接告诉Chrome调试器不要暂停。

const client = await page.target().createCDPSession(); await client.send('Debugger.enable'); await client.send('Debugger.setBreakpointsActive', { active: false }); // 禁用所有断点

这段代码通过CDP命令，全局禁用了所有断点的激活状态，自然也包括debugger语句。

4.2 Selenium (Python) 方案

Selenium本身不直接提供禁用debugger的API，但我们可以通过执行JavaScript代码或借助Chrome Options来实现。

方案一：使用Chrome DevTools Protocol (CDP) 命令现代Selenium支持执行CDP命令，这与Puppeteer的思路二异曲同工。

from selenium import webdriver from selenium.webdriver.common.desired_capabilities import DesiredCapabilities caps = DesiredCapabilities.CHROME caps['goog:loggingPrefs'] = {'performance': 'ALL'} # 可选，用于接收CDP日志 driver = webdriver.Chrome(desired_capabilities=caps) # 执行CDP命令，禁用断点 driver.execute_cdp_cmd('Debugger.enable', {}) driver.execute_cdp_cmd('Debugger.setBreakpointsActive', {'active': False}) driver.get('https://目标网站.com')

实操心得：execute_cdp_cmd是Selenium与浏览器底层调试协议通信的桥梁。确保你的Selenium和ChromeDriver版本较新（建议Selenium 4.x以上），以支持完整的CDP功能。

方案二：通过Chrome Options加载禁用debugger的扩展这是一个“奇技淫巧”，但非常有效。我们可以创建一个简单的Chrome扩展，在页面上下文中重写debugger。

1. 创建扩展文件夹，例如disable_debugger_extension，里面包含两个文件：
   • manifest.json:

   { "manifest_version": 3, "name": "Disable Debugger", "version": "1.0", "content_scripts": [{ "matches": ["<all_urls>"], "js": ["content.js"], "run_at": "document_start" }] }

   • content.js:

   // 在document_start阶段运行，覆盖debugger window.debugger = function() {}; // 或者拦截setInterval等函数，过滤掉包含debugger的调用（更复杂但更全面）

2. 在Selenium中加载这个扩展：

from selenium import webdriver options = webdriver.ChromeOptions() options.add_argument('--disable-blink-features=AutomationControlled') # 可选，禁用自动化控制标志 options.add_experimental_option('excludeSwitches', ['enable-automation']) # 可选 # 加载解压的扩展 options.add_argument('--load-extension=/path/to/disable_debugger_extension') driver = webdriver.Chrome(options=options) driver.get('https://目标网站.com')

这个方法的优点是“一次编写，到处运行”，扩展会被加载到每个页面中。缺点是配置稍显复杂，且需要处理扩展的路径问题。

5. 高级对抗与动态debugger的应对

有些网站的反爬策略会更进一步，它们部署的debugger不是静态的，而是动态生成、混淆或加密的，甚至会和其他的反爬手段（如鼠标移动轨迹检测、WebDriver检测）结合使用。

5.1 应对动态注入的debugger

如果debugger代码是通过eval、Function构造函数或setTimeout/setInterval动态生成的，仅仅覆盖初始的debugger关键字可能不够。

• 策略：需要更早地介入。在Puppeteer中，除了evaluateOnNewDocument，还可以考虑使用Page.addScriptTag在页面加载早期注入一个更强大的拦截脚本，重写eval、Function、setTimeout和setInterval等函数，对传入的代码字符串进行过滤。

// 示例：重写setInterval，过滤掉包含debugger的代码 const originalSetInterval = window.setInterval; window.setInterval = function(callback, delay, ...args) { if (typeof callback === 'string' && callback.includes('debugger')) { console.log('Blocked setInterval with debugger'); return null; // 直接返回null，不执行 } return originalSetInterval.call(this, callback, delay, ...args); };

注意：这种重写原生API的操作风险较高，可能影响页面正常功能，需谨慎测试。

5.2 结合其他反爬措施的复合型debugger

有些网站会检测开发者工具是否打开（例如通过检查窗口外尺寸、调试器属性等），仅在检测到调试行为时才触发无限debugger。

• 应对方法：除了绕过debugger，还需要隐藏自动化特征。在Puppeteer/Selenium中，需要启用更多的 stealth 插件或选项。
  • Puppeteer：使用puppeteer-extra和puppeteer-extra-plugin-stealth。
  • Selenium：通过options.add_experimental_option('excludeSwitches', ['enable-automation'])和options.add_argument('--disable-blink-features=AutomationControlled')来隐藏WebDriver特征。

5.3 无头模式(Headless)下的特殊问题

在无头模式下，debugger语句的行为有时与有界面模式不同。可能无头模式下一开始就卡死。

• 排查步骤：
  1. 首先尝试在非无头模式（headless: false）下运行你的脚本，确认绕过方案是否有效。
  2. 如果非无头模式有效，但无头模式无效，检查是否是无头模式特有的检测。可以尝试使用“新无头模式”（--headless=new，Chrome 109+），它更接近真实浏览器环境。
  3. 确保在无头模式下，你的CDP命令或脚本注入代码同样得到了执行。有时页面加载时序在无头模式下略有差异，可能需要使用page.waitForNavigation或更明确的等待条件。

6. 常见问题排查与实战技巧实录

在实际爬虫项目中，绕过debugger rarely是孤立的问题。下面是我踩过的一些坑和总结的技巧。

6.1 问题排查清单

6.2 实战技巧与心得

1. 优先使用非侵入式方案：在能满足需求的前提下，优先选择条件断点、禁用所有断点或CDP命令setBreakpointsActive。这些方法不修改页面运行环境，副作用最小。
2. 注入脚本是双刃剑：evaluateOnNewDocument和加载扩展是强大的武器，但务必清楚你注入的代码在做什么。避免引入新的不稳定因素。注入的代码应尽可能简单、专注。
3. 组合拳策略：对于复杂的网站，单一方法可能失效。可以采用“CDP禁用断点 + 脚本注入覆盖 + Stealth模式”的组合策略，层层设防。
4. 调试是爬虫的一部分：不要只想着完全自动化。遇到棘手的反爬，先用浏览器手动模式，配合开发者工具的Overrides、Ignore list等功能，把核心的请求逻辑和参数生成算法逆向清楚。自动化绕过脚本是基于你对原理的理解来编写的。
5. 尊重robots.txt与法律法规：所有的技术讨论都应在合法合规的范围内进行。在实施爬虫前，务必检查目标网站的robots.txt文件和服务条款，明确其数据抓取政策，避免法律风险。

绕过无限debugger只是爬虫与反爬虫对抗中的一个小关卡。它考验的是你对浏览器调试机制和JavaScript运行原理的理解。掌握这些方法，不仅能让你更顺畅地完成爬虫工作，也能加深你对前端安全与调试技术的认识。在实际操作中，保持耐心，多观察、多试验，你会发现大多数看似坚固的防御，都能找到优雅的通行之道。