什么是 Crawlee？

Scrapeless Agent Browser 为需要 JavaScript 渲染的自动化工作流提供远程浏览器基础设施。

Crawlee 是一个开源的爬取和网页抓取库，提供 JavaScript 和 Python 实现。它负责组织诸如处理 URL、选择基于 HTTP 还是基于浏览器的执行方式、抽取记录以及保存结果等任务。爬虫框架在页面之间协调工作；它既不同于浏览器引擎，也不同于承载该浏览器的基础设施。

一旦脚本的工作量超过一次页面访问，这种区分就变得有用了。你需要知道有哪些 URL 属于这次任务，哪些已经处理过，以及每条结果应该保存到哪里。Crawlee 为这种编排提供组件，而你的处理器仍然负责决定什么才是有效的记录。

Crawlee 为页面脚本带来了什么附加价值

Crawlee 在获取或打开页面的代码外围增加了抓取编排。其 爬虫框架架构 包括请求存储、结果存储、浏览器管理以及基于资源感知的调度。具体的类和选项取决于你所使用的语言实现和版本。

独立脚本可能只会打开一个 URL 并打印标题。一次抓取还必须管理周边决策：URL 来自哪里，是否应该访问它，应该由哪个处理器来处理它，以及它的结果如何与数据集中的其他部分关联。即使页面本身很容易解析，这些问题仍然存在。

不要把框架自动化理解为完整的抽取规范。Crawlee 并不知道哪个价格对应你要衡量的那个产品，也不知道空结果是否有效。你的应用需要明确的选择器或解析规则、必填字段，以及与数据任务相匹配的完成条件。

请求队列定义了前沿

请求队列表示等待处理的工作，并帮助一次抓取追踪其进度。它是已发现 URL 和完成处理之间的前沿，而不是最终数据集。

URL 的标识需要谨慎对待。当涉及跟踪参数或替代路径时，不同的 URL 可能标识相同的内容。相反，一个查询参数也可能选择不同的语言、类别或结果页。先要确定 URL 的哪些部分会改变所请求的内容，再对其进行规范化或去重。

将范围发现与抽取分开。一个类别页面可以用来发现产品链接，而产品处理器则收集详细记录。将发现限制在预期的主机和路径上，这样导航链接就不会把无关的账户、支持或搜索页面拉入任务中。

对于有边界的目录抓取，定义一个允许的 URL 家族和一个最大任务范围。当队列中不再包含更多被允许的工作时，根据预期库存评估输出的完整性。如果发现规则排除了有效页面，仅凭队列被耗尽并不能证明抓取完整。

HTTP 爬取和浏览器爬取有不同的成本

HTTP 爬取适用于响应中就已存在的内容，而浏览器爬取适用于需要页面执行或交互才能获得的内容。先检查所需信息是如何到达页面的。

HTTP 爬虫可以获取 HTML 并在不创建浏览器的情况下解析它。如果所需的值已经存在于该响应中，就可以避免渲染开销。如果应用在加载后通过 JavaScript 构建其记录，则可能需要浏览器来复现可见状态。

“ HTTP 请求和响应语义 ”定义了传输行为，但成功的响应并不保证记录可用。在接受结果前，验证内容类型、预期的页面标识以及必需字段。

混合抓取可以为不同页面类型使用不同处理器。当记录表示同一实体时，保持输出契约一致，但要保留来源信息，以便说明每个值是通过哪条路径产生的。

请求处理器将页面转换为记录

请求处理器是特定于应用的步骤，用于解释响应或浏览器页面。它应当把页面标识与要存储的记录关联起来。

对于产品任务，首先要确认最终页面仍然代表预期的产品。然后找到相关字段，并决定如何表示缺失的值。显示的零、缺失的价格以及解析失败不应在无声无息中变成同一个值。

围绕页面角色来设计处理器。列表页负责发现详情；详情页负责抽取实体；支持性页面可能提供元数据。清晰的角色区分有助于判断任务是失败在发现阶段还是抽取阶段。

在浏览器处理器中等待有意义的应用条件。导航事件可能发生在记录渲染之前，而可见容器在其内容仍在加载时就已存在。条件应反映处理器即将读取的数据。

数据集存储与抓取进度相互独立

结果存储保存提取出的输出，而请求存储跟踪工作进度。保持这些职责分离有助于你检查未完成的任务，并避免将已访问的 URL 误认为是有效记录。

在收集大样本之前先选择一个模式(schema)。在存在稳定实体标识符时将其包括进来，同时存储来源 URL，以及下游流程实际需要的字段。在关心新鲜度时保存提取时间；如果规范化可能隐藏有用上下文，则要区分原始值和规范化后的值。

当通过多个类别发现到同一条目时，一个数据集可以包含重复实体。将实体去重视为一个独立的数据决策，而不要假设队列去重已经解决了这个问题。URL 唯一性与业务实体唯一性是不同的需求。

直接检查已存储的输出。一个处理程序即使在结束时未抛出异常，仍可能产生空白字段或错误的页面标题。在合理的情况下为记录数量、必填字段覆盖率以及源页面到记录的样本匹配定义验收检查。

会话和资源限制需要明确的策略

一次抓取需要状态策略和资源策略，因为页面行为和浏览器容量会改变工作如何被调度。围绕目标工作流选择这些策略，而不是仅仅出于普遍想要最大化并发请求的愿望。

状态会影响内容。 浏览器 Cookie 模型 可以保留语言偏好、同意决定或账户标识符。决定每个任务应使用全新的环境还是延续已授权身份，并防止无关任务继承该身份。

资源限制应反映执行路径。浏览器页面消耗的内存和 CPU 组合与 HTML 解析不同。测量具有代表性的工作负载，然后设置有边界的并发和作业限制，使输出质量保持可观察。

在需要权限或人工操作的访问边界处停止。抓取配置本身并不是收集受限信息的授权。将抓取保持在预期的公共或其他已授权范围内，并最小化保留的账户或个人数据。

Crawlee 与远程浏览器基础设施的关系

Crawlee 负责协调抓取，而远程浏览器服务负责承载浏览器执行。这两层即使在同一工作流同时需要时，也可以分别进行评估。

Scrapeless Agent Browser 提供托管的浏览器环境，而其 Puppeteer 连接接口 记录了一种让客户端控制该环境的方式。Crawlee 部署需要兼容的浏览器池配置，并明确拥有远程连接的所有权。

如果拟议架构使用 Crawlee 和托管浏览器，请在单独的集成测试中验证具体的连接路径、上下文所有权和清理行为。爬虫的队列应对工作负责，而浏览器生命周期应对执行资源负责。

这种分层也在 Node.js 托管浏览器讨论中进行了说明。根据工作负载中属于浏览器的部分审查 Scrapeless 方案 ；框架存储和应用处理仍然是各自独立的运维关注点。

结论

Crawlee 组织围绕抓取的工作：发现 URL、处理正确的页面类型、提取定义好的记录并存储结果。主要的设计决策包括抓取范围、执行模式、状态所有权和输出验证。从有边界的样本开始，在扩展抓取前检查其中的记录。