开源爬虫项目选型：先分清四类分工，再比四个维度

在 GitHub 上搜爬虫，能翻出成百上千个仓库。很多人挑项目的办法是看 star 数，挑最热的那个用起来。

热门程度和适不适合你是两件事。一个项目再热，定位跟自己的场景对不上，用起来只会更累。省事的入口是先分清分工：一个能长期跑的采集系统本来就是几块职责不同的部件拼起来的，搞清每块在干什么，再去比具体实现，纠结会少很多。

通用爬虫框架：结构规整的页面靠它

这类框架管的是请求调度、并发抓取和数据管道，输入是一批 URL，输出是结构化结果。生态成熟，中间件机制能插自己的逻辑，百万级的长期任务靠它跑得住。

它处理不了需要 JavaScript 渲染的页面。内容是脚本跑完才出现的，它拿到的就是空壳，得再挂一个渲染引擎。适合列表页、详情页、开放接口这类结构稳定的目标。

浏览器自动化框架：要渲染、要交互的页面

需要真实渲染、需要带登录态、需要点几下才出内容的页面，只能交给浏览器自动化。它能跨内核跑，等待机制比较成熟，页面里的请求和响应也能直接接管。

代价是资源消耗远高于纯请求方式，并发上限基本由本机内存和 CPU 决定；另外自动化本身会留下特征，检测严格的站点能识别出来。

调度与队列组件：任务多了才需要

目标少的时候，一个循环就够。任务上千、还要控制频率和重试之后，得有单独的调度层：任务怎么排队、并发开到多少、失败了隔多久再试、哪些任务该放弃。这些逻辑塞进采集框架里，会越写越乱。

自己拼这一层最常见的坑是拿进程内的队列凑合。进程一重启，排队等着处理的任务全没了。队列至少要能持久化，能查状态。

解析与存储组件：决定数据能不能直接用

抓回来的是 HTML，用得上的是字段。解析这层要做抽取规则管理、字段校验、去重和落库。结构经常改版的站点可以看看有没有自适应抽取的方案，靠页面特征而不是写死的选择器定位数据，能省掉不少维护。

存储侧要留意幂等。任务重试是常态，写入得按唯一标识去重，否则重复数据会一路污染到下游分析。

拼起来之后容易出的问题

分开看每块都不难，组合起来问题通常出在接缝上。

• 调度层重试了，解析层没去重，数据里出现重复行
• 浏览器层没有并发上限，本机资源被吃满，整批任务一起挂
• 解析规则写死在代码里，站点一改版就得重新发版
• 各组件对一次任务的标识不统一，状态对不上，断点续跑无从谈起

四个评估维度

类别定下来之后，用这四项去筛具体项目。

维护活跃度看最近几个月的提交频率和 issue 响应速度，而不是总 star 数。停止维护的项目在目标站点改版之后会直接失效。

文档和示例决定上手成本。文档写得含糊，或者只有最简单的例子，学习时间往往超出预期。

扩展方式看它留了什么口子：能不能换代理、能不能接自己的渲染引擎、能不能替换存储。留了口子的项目，后续改造不用动源码。

许可证和合规风险容易被跳过。商用之前确认许可证类型，避开限制性授权；采集范围、请求频率和目标站点的条款也要一起评估，这部分和框架选得好不好无关。

环境层是另一个层次的事

框架解决怎么抓，身份和规模的问题它不管。任务需要登录、需要区分地区、需要多个账号并行的时候，全跑在同一个浏览器环境里会出两件事：会话互相污染，不同任务的 Cookie 和本地存储彼此覆盖；目标站点把本来不相关的任务看成同一批访问。

成熟的做法是把浏览器环境做成独立的资源层，任务从环境池里申请，用完释放。PurpleMark 在这类架构里就是这一层，提供可批量创建、可绑定独立网络出口、状态可查询的环境资源。

合规上要划的线

遵守目标站点的 robots 协议和服务条款，不采集个人信息，不绕过技术保护措施，控制请求频率别影响对方服务的正常运行。选型解决的是效率问题，这些判断解决的是能不能做的问题。