写爬虫的网络人多少都碰过这样的场景：目标网站的反爬策略三天一小改、五天一大改，爬虫上周还能跑的工具脚本这周就返回 403。我去年帮朋友抓一个地方论坛的网络二手房数据，前前后后换了四套方案，爬虫从最朴素的工具 requests 一路折腾到 Playwright，才算把数据稳定拿下来。网络

大多数人的爬虫第一个爬虫，代码不超过二十行。工具用 Python 的网络 requests 发个 GET 请求，拿回 HTML，爬虫再用 BeautifulSoup 或 lxml 把想要的工具字段抠出来。这套组合对付静态页面够用，网络速度快，爬虫资源占用低。工具问题在于，现在纯静态的站点越来越少了。你打开一个页面，右键查看源代码，发现正文内容是空的，数据全靠 JavaScript 渲染出来——这时候 requests 拿到的只是一个壳。

Scrapy 是另一个绕不开的名字。它把请求调度、去重、中间件、管道这些东西都封装好了，适合规模稍大的采集任务。我见过有人用 Scrapy 管理上万个域名的抓取队列，配合 Redis 做分布式，跑得挺稳。但 Scrapy 的学习曲线比 requests 陡不少，光是理解它的异步机制和中间件顺序就够喝一壶。如果只是抓几个页面，杀鸡用牛刀，反而浪费时间。

真正让人头疼的是反爬。简单的有 User-Agent 检测、IP 频率限制，进阶的有验证码、行为分析、蜜罐链接。我遇到过最阴的一招是：页面里藏了一个对普通用户不可见的链接，只有爬虫会去点，一旦点了，IP 直接被拉黑。这种设计就是专门钓鱼的。应对办法无非几种——换代理池、模拟真实浏览器指纹、控制请求节奏。但说到底，这是一场猫鼠游戏，没有一劳永逸的方案。

所以 Playwright 和 Puppeteer 这类浏览器自动化工具才越来越流行。它们直接驱动一个真实的 Chromium 实例，页面怎么渲染，爬虫就怎么看到。代价是慢，一个页面动辄几秒，内存开销也大。我现在的习惯是：能用接口拿数据就优先找接口，找不到接口再用 requests，requests 搞不定才上浏览器自动化。分层处理，效率最高。

还有一点容易被忽略：robots.txt 和法律法规。技术上能抓，不代表可以随便抓。个人研究和小规模数据采集，多数站点不会太计较；但如果你高频请求、抓取用户隐私数据、或者把数据用于商业用途，法律风险是实打实的。国内已经有几起爬虫相关的判例，值得每个写爬虫的人翻一翻。

工具终究只是工具。requests 也好，Scrapy 也好，Playwright 也好，选哪个取决于你要解决的问题。先把目标网站的结构摸清楚，再决定用什么武器，比一上来就套框架靠谱得多。