采集工具对比：四类路线与反爬应对成本

写一个能跑通的采集脚本不难，难的是让它跑上几个月还不崩。要处理的东西比几年前多：JavaScript 渲染的页面、验证码、访问频率限制、Cookie 校验、设备指纹识别。工具清单越拉越长的时候，第一个问题不是选哪一款，而是你的任务属于哪一类能力路线。

纯 HTTP 请求库

直接发请求拿 HTML，不启动浏览器。动态内容基本拿不到，页面靠脚本渲染出来的部分全是空的。并发与成本是它的优势，单机并发可以拉得很高，资源占用最低。代价是反爬要全靠自己：请求头、会话、代理、频率控制，都得手写，目标站点一升级检测策略，跟进的人也是你。合规上最容易出问题，无节制的高频请求对目标站点的压力最直接，也最容易踩到条款。

浏览器自动化框架

驱动一个真实浏览器，点击、输入、等待、读 DOM。动态内容支持最完整，JS 渲染、交互流程、登录都能覆盖。并发上要付出实打实的成本，每个实例都吃内存和 CPU，规模上去之后，进程管理、崩溃重试、资源回收都得自己写，这部分工作量常常超过写采集逻辑本身。反爬方面，拿到的是真实渲染结果，但自动化特征本身可以被识别，比如自动化标志位和无头模式的痕迹，需要单独处理。合规风险相对可控，问题主要出在把自动化用在违反站点条款的用途上。

带环境隔离能力的浏览器

在浏览器自动化的基础上，每个采集身份拥有独立的浏览器指纹、Cookie、本地存储和网络出口，指纹与 IP 的地理信息可以配套配置，IP 在哪个地区，时区和语言就跟到哪个地区。动态内容支持与上一类相同。并发代价多了一层：环境要按需启动、跑完就释放，否则资源会被一批闲置环境吃掉。反爬上，它的价值是把身份做干净，降低因为环境单一被关联的概率，但它不解决采集速度，也不替你处理目标站点的规则。合规上，隔离解决的是多个合法身份互不干扰，不是绕过规则。PurpleMark 属于这一类，提供浏览器环境的隔离与集中管理，每个采集身份对应一个独立环境。

云端采集服务

把代理轮换、页面渲染、人机校验处理打包成一个接口，你发一个地址，它回一段内容。动态内容通常支持，但渲染往往是一个单独的模式，按次或按量计费。上手最快，不需要维护基础设施，代价是单位请求成本最高，量一大就变成主要开支。反爬应对表面上最省事，实际是被转成了依赖：目标站点改版或识别策略升级时，你无法自己干预，只能等对方更新，业务节奏被供应商牵着走。合规责任也容易变模糊，采集行为算在谁头上并不因为你用了托管服务而转移。

动手之前先回答四个问题

需要登录态吗。需要的话，纯请求库基本可以排除。需要地区视角吗。需要的话，环境要能把 IP、时区、语言配套绑定，只换出口不改内部参数意义不大。并发规模多大。超过几十个，就要优先考虑具备环境管理和调度能力的路线，而不是靠加机器硬扛。数据价值能覆盖单位成本吗。高价值小批量，云端服务可以接受；大批量低价值，只能自建把成本压下来。

合规边界

采集行为要遵守目标站点的 robots 协议、服务条款和当地法律，不采集个人信息，不绕过技术保护措施，不影响对方服务的正常运行。身份隔离解决的是多个合法身份之间如何互不干扰，不是如何规避规则。

仅用于技术研究与开发实践分享，请在合法合规前提下使用相关技术。