写爬虫抓一个页面，网页requests加BeautifulSoup，批量二十行代码搞定。采集要抓一百个页面呢？网页循环一百次？服务器没封你IP算客气。网页批量采集的批量核心矛盾从来不是“怎么抓”，而是采集“怎么不被封、不把本地跑炸、网页不把数据搞乱”。批量

我去年帮人抓一个地方政策网站，采集大概三千多条公示文件。网页单线程跑，批量每条平均1.2秒，采集算下来一个小时。网页中间断了一次，批量从头再来。采集第二次我加了多线程，八个worker同时跑，速度上去了，结果对面WAF直接给我返回403。换了UA、加了referer，撑了十分钟又被识别。后来降回三个线程，随机sleep 0.5到2秒，才勉强跑完。三千条数据，折腾了整整一个下午。

并发不是越高越好

新手最容易犯的错就是觉得线程越多越快。你开五十个线程，目标服务器每秒收到五十个请求，它不封你封谁。合理的做法是先测单IP的容忍阈值——从1个并发开始，逐步加到被限速或返回异常为止，然后退回到阈值的60%左右。如果目标站点有CDN，不同IP的限速策略可能不一样，还得考虑分布式。

另一个坑是DNS解析。每个请求都重新解析域名，开销不小。用requests的Session对象可以复用TCP连接，实测能省掉大约30%的时间。这个细节很多人忽略，但在批量场景下效果很明显。

数据落地比抓取本身更麻烦

抓回来的HTML直接存文件？三千个文件散在磁盘里，后续清洗时找都找不到。我习惯用SQLite做中间层，每抓一条就写一条，字段包括URL、状态码、抓取时间、原始HTML。这样即使程序崩了，已抓的部分不会丢，下次跑的时候查一下哪些URL已经存在，跳过就行。断点续爬这个能力，在批量采集里是刚需，不是锦上添花。

去重也是个事。有些网站同一个内容挂在不同的URL下，参数不一样但页面一样。我一般对正文内容做MD5，存到数据库里做唯一索引。遇到过最离谱的情况是一个网站用session id做URL参数，同一个页面每次访问URL都不同，MD5去重直接救了我。

解析这步别偷懒

批量采集的页面结构往往不统一。列表页和详情页的DOM差异大，有些页面还缺字段。我见过有人写一个万能正则硬匹配所有页面，结果字段错位，数据全废。靠谱的做法是按页面类型分开写解析器，每个解析器单独测试。字段缺失就留空，别用默认值填充——默认值会让后续分析产生假象。

编码问题也绕不开。中文网站GBK和UTF-8混用是常态，requests的自动识别经常翻车。我的经验是先用chardet探测，再结合响应头里的charset做判断，两个不一致时以页面meta标签为准。听起来繁琐，但比事后修乱码省事得多。

留个后手

批量采集跑起来之后，你不可能一直盯着。加个简单的日志系统，记录每个URL的成功/失败状态和耗时。失败的重试一次，再失败就标记出来人工看。我还会在脚本里设一个总请求数上限，防止死循环把目标站拖垮——这既是保护对方，也是保护自己。

说到底，批量采集是个工程活，不是写个循环就完事。控制节奏、管理状态、处理异常，这三件事做好了，剩下的就是体力劳动。

(责任编辑：综合)