#4145·crawlee

`BrowserFetchHttpClient`: 使用已登录的页面作为 HTTP 客户端

作者: janbuchar创建于 2026年9月18日更新于 2026年9月18日

标签t-tooling

与 #3040、#3283 以及讨论 #3217 有关; crawlee-Python 中的先进技术: PlaywrightHttpClient (apify/crawlee-Python#1134) - 重复的模式: 在浏览器中打开一个网站(登录、防止机器人),然后从该页面使用内页 fetch() 获取许多 API/HTML URL,因为 CheerioCrawler 被阻止,而浏览器的 TLS/HTTP2 指纹、Cookie 和服务工作者却没有。今天人们在 PlaywrightCrawler 处理器中手动实现爬虫循环(fetchNextRequest、reclaimRequest/重试计数)。 - 使用 v4 BaseHttpClient 协议,这是一个约 50 行的客户端: fetch() 运行 page.evaluate(fetch(...)), 重建 ResponseWithUrl, 并在 401 时重新运行 login 回调。插入到 CheerioCrawler 中作为 httpClient 后,它返回队列、重试、统计数据、事务、$ / json 和真正的并发性(在同一页面上同时调用 evaluate(fetch) 都没有问题,没有任何导航)。使用重试、四路并发和中途重新登录进行了本地验证。 - 值得记录的约束: 与登录留下的页面共享同源(或 CORS); 禁止的头部(Cookie、User-Agent)和 Set-Cookie 是不可见的,因此浏览器容器具有权威性; CustomFetchOptions 中的 proxyUrl / fingerprint 被忽略(浏览器上下文决定)。 - Python 已经具备一半的功能: PlaywrightHttpClient 是 PlaywrightCrawler 中 send_request 的默认 http_client,通过上下文变量绑定到当前页面,并调用 browser_context.request.fetch()(APIRequestContext)。它共享上下文的 Cookie 和代理,没有同源限制,但它是 Playwright 自己的 HTTP 堆栈,而不是浏览器的(指纹 TODO: apify/crawlee-Python#1055),而 crawl() / stream() 为 NotImplementedError,因此无法驱动爬虫。这里有两种值得区分的风格: 以 APIRequestContext 为基础(与 Python 保持一致,对于在浏览器爬虫中使用 sendRequest 来说是一个很好的默认值)和以内页 fetch() 为基础(浏览器 TLS、源绑定) - 第二种是取代手动编写的循环的方式。 - 将其放在 FetchHttpClient 旁边,或者在 HTTP 客户端指南中记录此模式;它更直接地回答了"在登录后进行抓取"的问题,而不是页面级登录辅助程序。

内容来源: apify/crawlee

查看 GitHub 原文在 GitHub 查看讨论