核心结论：爬虫生态数万个工具的繁荣不是技术丰富的标志，而是持续对抗中高损耗率的副产品。爬虫问题的本质不是'能不能爬到'，而是全链路成本函数——爬、存、ETL、维护——谁先扛不住。
一、爬虫技术体系全景
1.1 技术类别收敛图
工具数万，但底层技术类别高度收敛。整个爬虫技术栈可以压缩为以下几层：
┌──────────────────────────────────────────────────────┐
│ 应用层（目标适配） │
│ 针对特定网站的解析规则、登录流程、分页逻辑 │
├──────────────────────────────────────────────────────┤
│ 解析层（数据提取） │
│ HTML 解析、JSON 提取、正则、XPath、CSS 选择器 │
├──────────────────────────────────────────────────────┤
│ 渲染层（页面执行） │
│ 静态请求（requests/httpx）vs 动态渲染（浏览器引擎） │
├──────────────────────────────────────────────────────┤
│ 伪装层（反检测） │
│ 指纹伪装、代理轮换、行为模拟、验证码处理 │
├──────────────────────────────────────────────────────┤
│ 调度层（任务管理） │
│ 并发控制、队列管理、去重、重试、分布式协调 │
├──────────────────────────────────────────────────────┤
│ 存储层（数据落地） │
│ 文件系统、数据库、对象存储、消息队列 │
└──────────────────────────────────────────────────────┘
核心认知：六层架构，每层的技术选项不超过十几种。所有'几万个工具'都是这六层的排列组合。
1.2 核心框架/库（30-50 个有独立价值）
静态请求类
| 工具 | 语言 | 核心能力 | 适用场景 |
|---|---|---|---|
| Scrapy | Python | 完整框架，Pipeline 架构，中间件体系 | 大规模结构化爬取 |
| requests + BeautifulSoup | Python | 轻量组合，入门首选 | 小规模、简单页面 |
| httpx | Python | 异步 HTTP，HTTP/2 支持 | 高并发 API 爬取 |
| Colly | Go | 高性能，内存效率高 | 大规模、性能敏感 |
| Crawl4AI | Python | 原生 Markdown 输出，面向 RAG | LLM/RAG 数据管线 |
动态渲染类
| 工具 | 核心能力 | 成本特征 |
|---|---|---|
| Playwright | 多浏览器、自动等待、多语言绑定 | 单请求成本高（秒级），但稳定性好 |
| Puppeteer | Chrome/Chromium 控制，生态最大 | Node.js 生态，适合前端团队 |
| Selenium | 最老牌，兼容性最广 | 性能较差，但文档和社区最丰富 |
