Scrapling 检查点会保存已抓取的数据吗？

返回

Kevin Riedl

8 分钟 阅读 · 2026年11月3日
最近审核 2026年11月3日

下一篇

我们的 Scrapling 爬虫保存记录 A 后暂停，恢复运行时返回了 B 和 C。再次向同一路径导出 JSON，原文件被覆盖，A 也从这份导出中消失了。

不会。Scrapling 0.5 检查点不保存已提取的记录。它保存待处理请求和已见请求的指纹。抓取数据需要单独持久化，使用稳定的记录标识，并在续爬后核对结果。恢复的请求队列与新一轮运行的记录列表各有职责，检查点数据结构明确列出了保存范围。

实测日期：2026年11月3日。我们使用10月17日发布的 Scrapling 0.5，抓取三个本地 HTTP 页面。五个独立 Python 进程分别执行连续抓取、主动暂停、恢复、手动重放检查点和注入记录写入故障。

Scrapling 能为智能体的网页采集提供什么？

Scrapling 是一个 Python 网页抓取框架，整合 HTTP 客户端、浏览器抓取、解析器与并发爬虫。智能体可按页面是否需要渲染来选择抓取方式，提取逻辑仍使用同一套库。本次实测关注续爬后的抓取记录去了哪里。

发布版 README 列出了浏览器指纹模拟、JavaScript 渲染、重试、代理轮换、CLI 提取和 MCP 接入。项目采用 BSD 3-Clause 许可证。

自适应解析可在 HTML 改动后重新定位元素。自适应解析指南说明了保存元素属性和相似度匹配的机制。重新找到元素，并不意味着提取出的记录已经持久化。更完整的检索架构可参阅我们的 Wigolo 本地网页检索评估。

Scrapling 检查点会保存抓取记录吗？

Scrapling 0.5 检查点保存待处理请求和已见请求指纹。已收集的记录列表只属于本次运行，另外使用的数据库或导出文件由应用负责。在本次固定版本的实现中，爬虫引擎会在开始运行时清空记录列表。

每轮运行后导出时，这个区别会直接影响结果。0.5 版的 result.items.to_json(path) 将当前列表写到指定路径。导出实现会覆盖原文件，to_jsonl(path) 也以写入模式打开文件。两者都不会自动合并之前运行的数据。

你可以保留每轮独立的导出文件，也可以逐条写入数据库。下面的测试展示了反复使用同一导出路径的结果。

暂停、恢复和重放后，哪些数据还在？

Scrapling 实测中，恢复后的 SQLite 表仍有全部三条预期记录，同一路径的 JSON 导出却只剩 B 和 C。我们随后手动重放已保存的检查点，B、C 又被处理了一遍。追加日志累计五次写入，以记录标识为键的表仍只有三条记录。

测试页面通过本机回环 HTTP 提供固定的 A、B、C 三条记录。爬虫一次处理一个请求，关闭定时检查点，在 A 的数据库事务提交后暂停。每个阶段都启动新的 Python 进程。暂停、恢复与重放共用数据库和导出路径，对照组和故障组使用独立目录。

重放阶段是在恢复运行完成后，重新放回我们暂停时生成的检查点。它验证的是重复执行请求时的输出行为，没有模拟意外崩溃，也没有测量断电后能保留多少工作。

故障组的记录处理钩子在写入 B 前抛出异常，on_error 只记录错误，不重试。Scrapling 继续完成剩余抓取，预期记录清单的核对发现了缺项。

下载 Scrapling 检查点测试包与实测结果。其中包含本地页面、预期记录清单、工作进程与运行脚本、依赖版本、JSON 报告、追加日志和可阅读的数据库导出。

如何复现检查点测试？

在新的 Python 环境中安装 Scrapling 的 fetchers 扩展，再运行测试包。脚本会启动本地 HTTP 服务，依次创建五个工作进程，并独立检查导出文件与数据库记录。本实验只使用 HTTP，无需浏览器可执行文件、MCP 客户端或 AI 模型。

python3.12 -m venv .venv
mkdir -p .cache/pip .cache/tmp
PIP_DISABLE_PIP_VERSION_CHECK=1 PIP_CACHE_DIR="$PWD/.cache/pip" TMPDIR="$PWD/.cache/tmp" .venv/bin/python -m pip install -r requirements-tested.txt
.venv/bin/python run_fixture.py --output results-reproduced
.venv/bin/python verify_payloads.py --results results-reproduced

在 Linux 上解压测试包后，进入该目录运行上述命令。实测使用 Python 3.12.14，requirements-tested.txt 固定了对应的依赖版本。安装前，我们核对了 Scrapling 0.5 wheel 的公开 SHA-256：

366f0ec9f1e7e998900e6c5e3a4063ea34062326394ced64e5c389b690572726

在输出目录查看 summary.json、payload-validation.json 和各阶段报告。HTTP 服务在不同工作进程之间保持运行，确保检查点中的 URL 仍然有效。每次复现都会生成自己的检查点，进程 ID、本地端口和检查点字节内容可以不同。验证会将记录标识及字段内容与预期清单比较。

抓取到的记录应该存在哪里？

通过 on_scraped_item，将 Scrapling 记录写入应用负责的持久化存储，并采用符合采集范围的记录标识。成功提交后再从钩子返回。Scrapling 会等待该钩子完成再保留记录，但写入失败仍需明确的处理策略；唯一键无法补回从未成功提交的数据。

Spider 钩子接口提供了接入位置。下面是实际运行的数据库写入代码，省略了周围的观测记录逻辑：

self.database.execute(
    "INSERT INTO items (collection_id, item_id, payload_json) VALUES (?, ?, ?) "
    "ON CONFLICT(collection_id, item_id) DO UPDATE SET payload_json=excluded.payload_json",
    (self.manifest["collection_id"], item["id"], json.dumps(item, sort_keys=True)),
)
self.database.commit()

主键是 (collection_id, item_id)。upsert 会插入新行，或更新具有相同键的现有行。在这份固定的数据集中，A、B、C 反复写入时，各自仍对应同一行。下载包包含建表语句和完整钩子。

面对持续变化的数据，先决定新观测值应该覆盖旧值，还是保留为新版本。需要历史记录时，应将观测范围纳入标识。否则，去重可能覆盖你本来需要保留的证据。

生产集成需要可用于补处理的失败记录清单，或明确的重试策略，之后还要核对完整性。请针对实际存储端的故障验证这套策略；这个 SQLite 小型测试不能证明另一种数据库的事务恢复行为。

如何确认断点续爬后的数据完整？

将 Scrapling 持久化输出与计划采集的范围比较，核对预期记录标识和必需字段。本测试有独立的预期清单，所以 A 或 B 缺失时可以直接判定。真实网站需要单独确定抓取范围和发现方法，才能定义预期记录集合。请求队列处理完毕不能代替这一步。

高级爬虫指南介绍了暂停恢复、流式输出和输出钩子。用这些机制保留数据，再单独决定何时把整个数据集交给下游。

本例中，智能体或 RAG 索引若只读取恢复后导出的 JSON，就只能拿到两条记录。应从持久化存储中发布已经核对过的数据集。进程本身如何恢复是另一层问题，可参阅 AX runner 恢复与自托管指南。

MCP 服务器会改变这套持久化规则吗？

Scrapling 的 MCP 服务器向兼容智能体提供网页与浏览器操作，但本实验运行的是 Python Spider API。本次检查点实测不能证明某个 MCP 工作流的持久化行为。先明确智能体将返回内容存在哪里，再针对实际需要承受的中断验证这个存储。

v0.5 MCP 指南列出 16 个工具，涵盖请求会话、浏览器操作、定向提取、截图、网络检查和浏览器状态保存。登录状态与提取出的数据集仍需分别保存。

什么时候适合用 Scrapling 为智能体采集数据？

如果项目需要在 Python 中控制抓取、解析与爬虫行为，并且应用负责记录持久化，我们会考虑 Scrapling。先选一小批获准采集的内容，定义记录标识，执行恢复与重放，再检查存储结果。让下游依赖这份数据前，还应加入贴近实际的写入故障场景。

用有代表性的页面、必需的记录结构和重启要求，定义数据采集的验收测试。