爬虫实战：绕过无限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运行原理的理解。掌握这些方法，不仅能让你更顺畅地完成爬虫工作，也能加深你对前端安全与调试技术的认识。在实际操作中，保持耐心，多观察、多试验，你会发现大多数看似坚固的防御，都能找到优雅的通行之道。