网站抓取数据工具

用Python写爬虫的网站人，十有八九第一行代码是数据requests.get()。这行代码简单到让人产生错觉——网站数据唾手可得。工具现实是网站，你发出100个请求，数据可能60个被拒绝，工具剩下40个里还有一半返回的网站是混淆过的JavaScript渲染页面，真正的数据数据藏在浏览器执行完脚本之后才出现。

我去年帮一个做跨境电商的工具朋友抓竞品价格。目标网站看起来平平无奇，网站商品列表页用浏览器打开一切正常。数据用requests请求，工具返回的网站HTML里只有骨架，价格字段全是数据空的。换成Selenium驱动Chrome，工具等页面完全加载后再取DOM，数据出来了。但跑了不到200个页面，IP被封了。那段时间我试了七八种方案，最后稳定下来的组合是：Scrapy做调度框架，中间件里挂代理池，配合Playwright处理动态渲染。这套东西不优雅，但能跑。

抓取工具的选择取决于目标网站的技术栈。静态页面用requests+BeautifulSoup足够，半小时能写完一个。SPA应用就得上无头浏览器，Playwright比Selenium快，资源占用也低一些。遇到反爬严格的站点，比如某些招聘网站，它们会检测navigator.webdriver属性，你得在启动浏览器时注入脚本把这个标志抹掉。还有更狠的，用Canvas指纹识别，这种情况下即使用了无头浏览器也会被识别出来。

代理IP是另一个绕不开的坑。免费代理基本不能用，延迟高、存活时间短。付费代理也分三六九等，数据中心IP便宜但容易被封，住宅IP贵但成功率高。我现在的做法是按目标网站分池子，每个池子配不同的请求头策略和访问频率。一个池子被封了，切到另一个，给被封的池子时间恢复。

数据解析环节经常被低估。很多人以为拿到HTML就完事了，其实解析规则要跟着网站改版走。我维护过一个抓取新闻网站的脚本，三个月内网站改了两次DOM结构，第一次把div.article-content改成了article.post-body，第二次干脆把正文放进了Shadow DOM里。Shadow DOM里的内容用常规选择器取不到，得用element.shadowRoot穿透进去。这种改动没有任何通知，只能靠监控脚本报错来发现。

存储环节倒没什么新鲜的。小规模用CSV，中等规模上SQLite，数据量再大就扔PostgreSQL。我见过有人用MongoDB存抓取结果，理由是字段不固定。但实际用下来，关系型数据库的约束反而能帮你早发现数据质量问题——比如价格字段出现了字符串，插入时就会报错，逼你去检查解析逻辑。

法律边界得拎清楚。抓公开数据、遵守robots.txt、控制请求频率，这三条是底线。有些网站的用户协议里明确禁止抓取，你硬要抓，风险自担。我自己的原则是：不碰个人隐私数据，不绕过登录墙，不给目标服务器造成明显负担。做到这三点，大部分场景下不会出大问题。

工具终究是工具。有人用现成的八爪鱼、后羿采集器，拖拽配置就能跑，适合不写代码的运营人员。有人非要自己造轮子，觉得可控性更强。我的看法是：能用现成方案解决的，别重复造轮子；现成方案解决不了的，再动手写代码。省下来的时间拿去分析数据，比折腾工具本身有价值得多。