浏览器插件爬虫：一种被低估的爬虫方案

前言

刚刚看到一个博主写了一下浏览器插件爬虫。想想 这个自己做的还是比较早的。从popup 到 content.js 到servicesworker 场景也写了不少。就水一篇文章吧

提到爬虫，大部分人第一反应可能还是 Python 的 Scrapy、Playwright、Selenium，或者 Node.js 下的 Puppeteer。

但是随着各大网站反爬越来越严格，传统爬虫的成本也越来越高。

本文主要介绍一下浏览器插件爬虫这种方案，以及它相比传统爬虫的一些优势。

最后顺便介绍一下最近比较火的浏览器插件开发框架 —— WXT。

什么是浏览器插件爬虫？

简单来说，就是把原本运行在服务器上的爬虫代码，放到浏览器插件里面执行。

传统模式：

1
2
3
4
5
服务器
    ↓
HTTP请求
    ↓
目标网站

插件模式：

1
2
3
4
5
用户浏览器
    ↓
插件注入页面
    ↓
直接获取页面数据

插件运行在用户浏览器内部，它本质上已经成为浏览器环境的一部分。

而大部分网站设计的时候，本身就是给浏览器访问的。

这就导致：

浏览器插件天然拥有“真实用户”的身份。

传统爬虫的痛点

做过爬虫的人应该都遇到过这些问题。

登录问题

很多网站登录流程越来越复杂：

  • 短信验证码；
  • 滑块验证；
  • 人机验证；
  • 二维码登录；
  • 多因素认证。

传统爬虫需要模拟这一整套流程。

有时候验证码比业务逻辑都复杂。

其实这种很多基于风控行为的 到现在 你无论自动化还是插件或者RPC都不好解决。要不你就烧成本

Cookie维护

传统爬虫经常需要：

1
2
3
4
5
6
7
抓Cookie
↓
保存Cookie
↓
Cookie过期
↓
重新登录

维护成本很高。

尤其是你在做任何一个网站。哪怕你要短期获取数据。你也需要他的ck来获取数据。

反爬检测

例如：

  • User-Agent检测；
  • 浏览器指纹检测；
  • TLS指纹；
  • WebDriver检测；
  • Canvas指纹；
  • 行为检测。

很多网站甚至会检测：

1
navigator.webdriver

只要返回 true。

直接给你空数据。但时至今日 这种反爬应该有很多种解决方式了。这里也只是个举个例子

动态渲染

现在越来越多的网站：

1
2
3
4
React
Vue
Next.js
Nuxt

接口数据不一定好找。

很多时候只能：

1
2
3
4
5
6
7
启动浏览器
↓
等待渲染
↓
执行JS
↓
获取DOM

资源消耗很大。

插件爬虫的优势

天然拥有登录态

插件运行在用户浏览器。

Cookie 本身就在浏览器里。

例如：

1
chrome.cookies.getAll(...)

就可以获取当前域名 Cookie。

用户登录一次。

插件长期复用。

不需要重复登录。

这里用我写的图来表示下

用小红书来举例 像这种websession http only的cookie 正常document.cookie 无法获取的 。但是你通过Chrome插件就能很轻松获取了。

更像真实用户

插件本质就是浏览器的一部分。

很多检测根本不会触发。

例如：

1
navigator.webdriver

正常浏览器：

1
undefined

Selenium：

1
true

很多简单反爬在这里就失效了。虽然是简单反爬。但也是比较极致的伪装

直接读取页面DOM

传统爬虫：

1
2
3
4
5
requests
↓
HTML
↓
BeautifulSoup

插件：

1
document.querySelector(...)

直接获取。

例如：

1
const title = document.querySelector(".title")?.innerText;

简单粗暴。

当然这里还是有一些问题的 我用一张图来举例

内外dom要交互 需要发送message

获取接口数据更方便

插件可以 Hook：

1
2
fetch
XMLHttpRequest

例如：

1
2
3
4
5
6
7
8
9
const originFetch = window.fetch;

window.fetch = async (...args) => {
    const res = await originFetch(...args);

    console.log(args);

    return res;
};

很多隐藏接口。

页面自己就帮你调用了。

插件只需要监听即可。

PS ： 这里其实还有一些问题。比如XHR 和fetch的区别 有兴趣的同学可以加我微信细聊

资源消耗更低

如果使用 Playwright：

1
2
启动Chromium
≈ 几百MB内存

插件：

1
浏览器本来就在运行

几乎没有额外成本。

尤其适合：

  • 数据采集助手；
  • CRM插件；
  • 电商运营工具；
  • 招聘信息收集；
  • 社媒运营工具。

插件爬虫的劣势

当然。

插件也不是万能的。

依赖用户浏览器

无法像服务器一样：

1
24小时自动运行

用户关掉浏览器。

插件也停止工作。

发布审核

如果发布到 Chrome Web Store。

审核越来越严格。

尤其涉及：

  • 数据采集；
  • 自动化操作；

审核周期可能比较长。

遇到翻页验证码 逻辑复杂

要是真的遇到这种交互性的东西 可能逻辑就比较复杂。尤其是用了AI 你压根看不懂。

WXT：现代浏览器插件开发框架

以前写插件。

基本都是：

1
2
3
4
manifest.json
background.js
content.js
popup.html

纯手写。项目稍微大一点。维护起来就很痛苦。

后来接触到了 WXT。

个人感觉是目前体验最好的浏览器插件开发框架之一。

WXT 是什么？

这里直接丢一个官方链接： https://wxt.dev/

WXT 可以理解成：

浏览器插件领域的 Vite。

官方定位：

1
The web extension framework.

它帮我们处理：

  • 打包；
  • 热更新；
  • Manifest生成；
  • 多浏览器兼容；
  • TypeScript支持。

开发体验提升非常明显。

WXT的优点

支持主流框架

支持：

1
2
3
4
Vue
React
Svelte
Solid

开发 popup 页面体验和正常前端项目一致。

自动生成 Manifest

传统插件：

1
manifest.json

几百行。

WXT：

1
export default defineConfig({});

自动生成。

开发效率高

修改代码：

1
2
3
4
5
保存
↓
自动重新构建
↓
浏览器刷新

这一点真的舒服…

个屁。实际也会有BUG 各有各的好吧。

总结

这里我也不废话了 直接放图

优点还是比较多的。相当于web端重打包。本来想建群的。后面想想算了。现在AI直接秒杀了 哪有它不会的API～