Python 中的网页抓取——完整指南

原文 ↗ Hacker News 讨论 ↗

Python 中的网页抓取被认为强大但也日益复杂，实践者依赖 Playwright、Scrapy、requests-cache 以及第三方代理/CAPTCHA 服务来处理重 JavaScript 页面、速率限制和反机器人防护。评论者就 Python 与 Node.js 的抓取能力展开讨论，通常更偏好 Python，因为它在字符串处理、数据工具和成熟框架方面更强，同时也指出相比直接使用轻量 HTML 和 API 方法，浏览器自动化常常被过度使用。许多人强调架构最佳实践——例如将爬取与提取分离、缓存原始页面，并把抓取视为 ETL/ELT 流水线——以及 LLM 的新用途：生成或调整抓取器，而不是直接逐页解析。

基于浏览器的抓取工具

  • 对 Playwright 作为现代、稳健的浏览器自动化工具抱有强烈热情（被视为“selenium plus more”），其中代码生成和设备配置文件被认为是突出特性。
  • Shot-scraper（Playwright 的 CLI 包装器）因其便捷性以及与 Mozilla Readability 的集成而受到称赞，但也被指出在 CPU 上很重，在被调用成千上万次时效率低下；对于大规模运行，用户建议直接编写原生 Playwright 代码。
  • 对 Playwright 文档存在一些困惑：介绍部分强调与 pytest 的集成，这会误导那些只想使用该库的用户。

Python 与 Node.js 及其他语言

  • Python 的受欢迎程度归因于：
    • 长期存在的生态系统（例如 BeautifulSoup、lxml、Scrapy）。
    • 相比 JS，更容易进行字符串处理和数据重塑。
    • 相比 JS 的异步，更简单的同步思维模型。
    • 更容易与下游分析栈集成（pandas、数据库）。
  • Node/JS 被认为具有更符合人体工学的类 DOM API，但用于文本处理的标准库较弱。
  • Perl 和 Ruby 被认为在大量文本导向的抓取任务中非常有效。

抓取基础设施与服务

  • 提到了多种代理 + 渲染 SaaS 选项：ScraperAPI、ScrapingBee、Scraping Fish、Apify、Urlbox；用户反馈其可靠性和成本取舍各不相同。
  • 一些用户将代理/限流/会话逻辑抽离到独立的 proxy-manager 服务中，以保持抓取代码简洁。
  • 据报告，cloudscraper + 代理列表 + 线程化可实现很高的请求吞吐量。

反机器人防护、CAPTCHA 与规避

  • 抓取被描述为远未“死亡”，但难度更高：Cloudflare、Akamai、DataDome、CAPTCHA、认证墙。
  • 分享的战术包括：
    • 手机 IP 或住宅 IP（包括通过家庭连接/CGNAT 路由）。
    • API 逆向工程以及 JSON/LD+JSON/OpenGraph 提取。
    • CAPTCHA 求解服务（例如 2captcha）或本地基于 AI 的求解器。
    • 谨慎地试验速率、请求头和行为以模仿人类。
  • 有人认为绕过大型 WAF（Cloudflare/AWS WAF/Akamai）几乎不可能；也有人声称借助伪装工具和手机 IP 取得了成功。

设计模式：爬取、缓存与 ETL

  • 普遍共识：将爬取（HTML 获取）与抓取（数据提取）分离。
    • 存储原始 HTML 或缓存响应（例如 requests-cache、S3、SQLite），这样就可以在不重新爬取的情况下迭代提取器。
  • 这被表述为 ETL/ELT 最佳实践的一个实例：先落地原始数据，再进行转换。
  • 即使在早期实验阶段，也强烈推荐在 HTTP 客户端外层加上简单的缓存封装。

LLM 与自动化

  • 有些人正在构建系统，让 LLM 生成或调整抓取代码和策略，而不是把 LLM 用在每一次提取上（那样太慢/太贵）。
  • 其他人尝试将 LLM 用于截图/DOM，但指出上下文大小和稳健性问题；LLM 生成的正则以及传统解析仍然很有吸引力。

伦理、影响与站点视角

  • 一位站点运营者要求抓取者使用一致的 User-Agent 字符串，以便可以管理和负载均衡流量。
  • 另一位用户批评像 DataDome 这样的反抓取方案会降低正常浏览体验（尤其对轻量客户端而言），同时很可能并不能阻止认真的抓取者。

杂项提示与对指南的批评

  • 提示：使用 robots.txt 和站点地图；pandas read_html 可以简化表格提取；extruct 可以提取结构化元数据。
  • 有些人认为 BeautifulSoup + lxml 的性能争论并不重要，因为网络耗时占主导。
  • 几位评论者称这份“完整指南”很浅，且主要只是为推广某个特定的代理/抓取服务提供载体。