web数据抽取

抓网页这件事，据抽干过的据抽都知道，最省事的据抽办法往往最不牢靠。拿正则表达式去匹配HTML，据抽头两天跑得好好的据抽，第三个礼拜网站改了个class名，据抽整条流水线全趴窝。据抽我见过一个团队为了抓某电商平台的据抽商品价格，写了四十多条正则规则，据抽维护成本比养一个全职员工还高。据抽

HTML本身就是据抽个树状结构，用lxml配合XPath才是据抽正路子。比如想拿豆瓣读书列表页里的据抽书名，//div[@class="title"]/a/text()一行就够。据抽但问题来了——很多网站的据抽关键数据压根不在HTML源码里。你右键查看源代码，发现商品价格的位置是空的，数据是JS渲染完才塞进去的。这时候requests.get()拿到的就是个空壳。

应对这种局面，两条路。一条是老老实实上Selenium或者Playwright，开个无头浏览器把页面跑一遍，等JS执行完再取DOM。代价是慢，资源消耗大，十个并发就能把一台4G内存的机器拖垮。另一条路是找接口。打开浏览器开发者工具，切到Network面板，刷新页面，盯着XHR请求看。很多网站的数据其实是通过JSON接口传的，直接请求那个接口，返回的就是干净的结构化数据，连解析HTML都省了。我抓一个招聘网站的时候发现，它的职位列表接口就是/api/jobs?page=1&city=beijing，返回JSON里连薪资范围都给你算好了。

反爬是绕不开的坎。最常见的是User-Agent检测，这个好办，请求头里随便填一个浏览器的就行。麻烦的是基于行为的检测——比如同一IP在短时间内请求频率过高，或者鼠标轨迹不符合人类习惯。有个做价格监控的朋友跟我讲，他们抓某航司的票价，一开始用固定间隔请求，十分钟就被封了IP段。后来改成随机间隔、随机UA、加上代理池轮换，才勉强稳住。代理池的质量参差不齐，免费的基本不能用，付费的也得测，有些代理看起来能用，实际上返回的数据是缓存过的旧页面。

数据抽出来之后，清洗往往比抓取本身更耗时间。网页上的价格可能写成“¥1,299.00”，也可能写成“1299元起”，还可能藏在图片里。日期格式更是五花八门，有“2024-01-15”的，有“1月15日”的，还有“15/01/2024”这种。我一般先用BeautifulSoup或者lxml把文本抠出来，再用re做一轮粗提取，最后用pandas做类型转换和异常值过滤。这一步没什么捷径，就是对着数据一列一列看，写针对性的清洗规则。

存储环节看数据量。几千条数据用CSV就够了，几十万条上SQLite，再大就考虑MongoDB或者PostgreSQL。我自己的习惯是，不管最终存哪，先落一份JSON Lines文件到本地。好处是调试方便，出问题了直接grep一下就能定位。有次抓一个论坛的帖子，发现某几个页面的回复数对不上，翻出JSONL一看，原来是分页参数从page=1变成了start=0，改一行代码就解决了。

最后说个容易被忽略的点：robots.txt。很多人觉得这东西没法律效力，想抓就抓。但真出了事，它至少是对方主张你“明知故犯”的证据。我一般会看一眼，如果明确禁止抓取目标路径，就换个数据源或者直接找对方谈API合作。技术手段能绕过限制，但不代表应该绕过。