爬虫翻车在47页：3个改动让100页数据全活

上周二，一个Python脚本在第47页彻底崩掉。100页的目标只完成不到一半，之前抓的数据全部作废——因为作者太急，没做防封策略。

这事发生在电商数据抓取场景。目标很简单：商品名、价格、库存状态。但对方API锁在企业版定价后面，500美元/月。作者选择直接爬网页，结果付出了更贵的学费。

第一次尝试：裸奔式请求

代码很干净。一个for循环，requests库直接冲，BeautifulSoup解析HTML。没有任何延迟、没有身份伪装、没有断点续传。

服务器在第47页识别出机器行为，直接封禁。零数据回收，从零开始。

这像极了早高峰地铁闸机——你刷卡太快，系统判定异常，直接拦停。区别在于，地铁还能重新排队，爬虫的数据已经没了。

三处改动，从翻车到通关

作者第二轮做了三件事，全部针对"如何让自己看起来更像真人"。

第一：随机延迟

代码里加了两行：

time.sleep(random.uniform(2, 5))

每页请求之间随机等待2到5秒。人类浏览不会匀速点击，机器才会。这个改动让请求间隔呈现自然抖动，避开最简单的频率检测。

第二：轮换User-Agent

准备3到4个不同的浏览器标识，每次随机抽取。Windows版Chrome、Mac版Safari、不同版本号混着用。

服务器端的风控系统会读取这个字段判断客户端类型。固定标识等于自报家门"我是脚本"，轮换则增加识别成本。

第三：实时存档进度

每完成一页，把当前页码和已抓取数据写入JSON文件。如果中断，读取进度从断点继续，而非回到第1页。

这个设计改写了失败成本。第一次崩掉是100%损失，第二次崩掉最多损失一页。

时间换稳定性：15分钟 vs 2分钟

第二轮跑完全程用了15分钟，第一轮如果成功只需2分钟。但第一轮没有成功。

作者后来转向ParseForge这类托管服务处理更大规模任务，自动处理代理轮换、验证码识别、分布式调度。但对于中小项目，手写这三行防御代码仍是性价比最高的方案。

电商反爬和爬虫博弈了十几年。一方用机器学习识别行为模式，一方用随机化模拟人类。这场军备竞赛里没有绝对安全，只有成本权衡——让对方识别你的成本，高于你数据的价值。

那个在第47页被封的脚本，如果当初多加5分钟写防御逻辑，本可以省下几小时的返工。技术债的利息，总是比本金更贵。

你现在写爬虫会先做防封，还是等撞墙了再补？