AI-Chain
开源 Python 开发者工具 CLI Playwright MCP 人工智能

Scrapling：用自适应选择器把 Web Scraping 从一次性脚本升级成可持续爬虫

分享:
Scrapling：用自适应选择器把 Web Scraping 从一次性脚本升级成可持续爬虫

Scrapling：用自适应选择器把 Web Scraping 从一次性脚本升级成可持续爬虫

很多爬虫专案不是写不出第一版，而是网站改版后，CSS selector、DOM 层级与反爬策略一起变动，原本能跑的脚本很快变成维护负担。 Scrapling 的切入点不是再包一层 HTTP client，而是把 parser、fetcher 与 crawler 放进同一套可组合的 Python framework，并让选取器能在页面结构变动后尝试找回原本的元素。

本文以官方 repository 与 pyproject.toml 的目前内容为准，拆解 Scrapling 的核心设计，并用几个可直接改写成专案的范例，说明它适合哪些资料撷取工作。

先看专案定位

Scrapling（GitHub）是 BSD-3-Clause 授权的 Python Web Scraping framework，官方套件目前要求 Python 3.10 以上，pyproject.toml 的版本为 0.4.12。截至 2026 年 8 月 9 日，repository 显示超过 73,000 颗 stars，最近一次 push 在 2026 年 8 月 8 日，符合「高星且持续更新」的实作型开源专案条件。

它把功能分成四个层次：

  • Parser：解析 HTML、CSS/XPath 选择、文字搜寻与相似元素寻找。
  • Fetcher：从一般 HTTP request，到可处理 JavaScript 与 stealth browser 的不同抓取路径。
  • Spider：提供并行、节流、重试、pause/resume 与串流结果的爬虫框架。
  • 介面整合：CLI、Web Scraping shell，以及可让 AI agent 呼叫的 MCP server。

这种分层让你可以从一个 fetch 呼叫开始，之后再逐步升级成有 session、proxy、并行度与结果输出的 crawler，而不必整套换框架。

安装策略：先从 parser 开始

官方把浏览器与命令列能力拆成 optional dependencies，这是 Scrapling 很重要的使用边界。只需要解析已经拿到的 HTML 时，安装核心套件即可；要使用 fetcher、spider 或浏览器自动化，则要安装对应 extras。

若用 uv 管理专案，可以这样开始：

uv init scrapling-demo
cd scrapling-demo
uv add "scrapling[fetchers]"
uv run scrapling install

若需要 MCP server 或完整 shell 功能，可以改用：

uv add "scrapling[all]"
uv run scrapling install

scrapling install 会安装浏览器及其相关依赖。只执行 uv add scrapling 并直接 import scrapling.fetchers，不会得到完整的浏览器能力，这是新手最容易踩到的安装落差。

核心差异：把选择器变成可学习的定位

传统爬虫常把 selector 写死：

product = page.css(".product-card h2::text").get()

只要 .product-card 改成 .item-card，程式就会回传空值。 Scrapling 支援先在稳定版本的页面上保存元素特征，再在后续页面使用 adaptive selection 尝试找回相同语意的节点：

from scrapling.fetchers import StealthyFetcher
StealthyFetcher.adaptive = True
page = StealthyFetcher.fetch(
    "https://example.com/products",
    headless=True,
    network_idle=True,
)
# 第一次抓取时保存元素特征
products = page.css(".product-card", auto_save=True)
# 网站改版后，改用 adaptive=True 找回相似元素
products = page.css(".product-card", adaptive=True)
for product in products:
    print(product.css("h2::text").get())

这个机制不是保证任何改版都能自动修复，也不是取代测试。它的价值在于把「selector 失效后全部人工重写」变成「先尝试根据元素特征恢复，再由测试或监控确认结果」。对长期跑的资料管线来说，这个容错层比单纯追求更短的 CSS selector 更有用。

Fetcher：依页面难度选择抓取路径

Scrapling 没有把所有网站都当成同一种 request。官方 API 提供不同强度的 fetcher：

| 场景 | 建议入口 | 重点 | | --- | --- | --- | | 静态 HTML、追求速度 | Fetcher | 一般 HTTP、浏览器 impersonation 与 HTTP/3 支援 | | 需要 JavaScript 执行 | DynamicFetcher | 透过 Playwright/Chrome 载入动态页面 | | 需要更完整的 stealth 能力 | StealthyFetcher | fingerprint spoofing、session 与反自动化处理 | | 非同步工作流 | AsyncFetcher | 配合 async pipeline 使用 |

实务上可以先用最便宜的 HTTP 路径；只有在 HTML 不完整、需要登入状态或页面由 JavaScript 产生时，才升级到 browser fetcher。这能同时控制执行时间、记忆体与被封锁的风险。

另外，fetcher 支援 session、proxy rotation、remote browser、XHR capture 与 ad/domain blocking。这些能力适合资料来源较复杂的工作，但也代表你应该把请求速率、授权、robots.txt 与网站服务条款纳入设计，而不是把「能抓到」当成「可以任意抓」。

Spider：从单页脚本走向可恢复的 crawl

当资料量增加，真正难处通常不是 selector，而是重试、节流、断线恢复与结果交付。 Scrapling 的 spider API 以 async parse callback 为核心：

from scrapling.spiders import Spider, Response
class ProductSpider(Spider):
    name = "products"
    start_urls = ["https://example.com/"]
async def parse(self, response: Response):
        for item in response.css(".product"):
            yield {
                "title": item.css("h2::text").get(),
                "url": item.css("a::attr(href)").get(),
            }
ProductSpider().start()

官方 spider 层提供 configurable concurrency、per-domain throttling、blocked request detection、AutoThrottle、pause/resume、streaming，以及 JSON/JSONL/CSV/XML 汇出。也就是说，这段 callback 可以自然地往生产环境扩充，而不是把所有控制流程塞进一个巨大 while 回圈。

建议的生产化顺序是：

1. 先用 development mode 快取 response，反覆调整 parse() 而不重复打目标站。

1. 开启 robots.txt 遵循与合理的 domain concurrency。

1. 对 blocked response、空结果与 schema 变更加上明确监控。

1. 使用 pause/resume 及串流输出，把长时间任务和下游资料管线解耦。

CLI 与 MCP：让工具进入自动化工作流

不想每次都写 Python 时，可以使用 CLI：

uv run scrapling shell
uv run scrapling extract get \
  'https://example.com' \
  content.md \
  --css-selector '#content' \
  --impersonate 'chrome'

如果团队正在建置 AI agent，scrapling[ai] 会提供 MCP server 所需依赖，让 agent 能以工具方式取得网页内容。这里的重点不是「让模型自由浏览所有网站」，而是把 fetch、extract、输出格式与权限界线包成受控工具，并在 server 端留下请求纪录与限制。

效能数字要怎么看

官方 README 的 parser benchmark 显示，在 5,000 个巢状元素的文字撷取测试中，Scrapling 平均 1.98 ms，与 Parsel/Scrapy 的 1.99 ms 接近；在元素相似度与文字搜寻测试中，README 列出的平均时间为 2.29 ms。这些是 repository 作者提供、由 benchmarks.py 定义的特定基准，不应直接解读成所有网站与所有抓取路径都会快上相同倍数。

真正选型时，应把 parser benchmark、browser 启动成本、proxy、网路延迟、目标站反应与资料清洗时间分开量测。 Scrapling 的合理卖点是把稳定性与功能整合在一起，而不是一张脱离情境的速度排行榜。

适合与不适合的工作

适合：

  • 需要长期维护、网站结构可能变动的资料撷取。
  • 同一个专案同时包含静态页、动态页与需要 session 的页面。
  • 想从一次性脚本逐步升级到可重试、可恢复的 crawl。
  • 想把受控的网页撷取能力接到 CLI、MCP 或 AI agent workflow。

不适合直接套用：

  • 只需要一次性下载单一公开档案的任务；一般 HTTP client 可能更简单。
  • 对浏览器依赖、反自动化处理与执行环境极度敏感的 serverless function。
  • 需要保证完全绕过所有反爬机制的情境；没有任何工具能替代合法授权、流量治理与来源协议。

结论：它解决的是维护成本

Scrapling 值得注意，不是因为它把 Web Scraping 包装成另一个更大的 API，而是因为它把爬虫的三个生命周期放在同一个设计里：先抓到页面，再用能面对改版的定位方式取资料，最后以可恢复的 spider 把工作跑长。 CLI 与 MCP 则让同一套能力能接到更大的自动化系统。

如果你的痛点是「selector 每次改版都要重写」或「爬虫一上线就开始处理重试与断线」，Scrapling 是值得做小型 proof of concept 的候选。建议先选一个有测试资料的来源，记录 selector 恢复率、空结果率、单页延迟与浏览器资源成本，再决定是否把它推进正式资料管线。

使用 Web Scraping 前，请确认资料来源的授权、网站条款、robots.txt、个资与速率限制。 Scrapling 官方也明确提醒使用者遵守当地与国际资料撷取及隐私法律。

参考资料

  • Scrapling GitHub repository
  • Scrapling official documentation
  • Scrapling pyproject.toml
  • Scrapling parser selection guide
  • Scrapling spider architecture
  • Scrapling MCP server