这次事故，不是被封 IP。
也不是代理失效，更不是帐号过期。
说出来有点反直觉：
爬虫连页面“什么时候算加载完”都判断错了。
而且最糟糕的是，系统当时完全不知道自己已经出问题了。
一、事情是怎么发生的
我们有一套跑了挺久的内容采集系统，目标站点是典型的 JS 渲染页面。
技术选型其实很常规：
Playwright
亿牛云代理IP
固定 User-Agent等
定时任务，每 10 分钟跑一轮
这套系统稳定运行了三个月，中间基本没出过问题。
直到某天凌晨，业务同事发来一句话：
“数据怎么少了一半？”
二、监控看起来一切正常
我第一时间去看监控。
老实说，当时心里是有点踏实的。
请求成功率接近 100%。
页面加载时间没有异常。
代理 IP 的可用率也很高。
CPU 和内存都很平稳。
从系统视角来看，这套爬虫运行得非常健康。
但业务数据很快打破了这种错觉：
关键字段大量为空。
原本几十条的数据列表，只剩下十几条。
偶尔看起来“正常”，但整体在持续缩水。
这是最让人头疼的一种状态：
系统没有报错，但结果已经开始不可信了。
三、我们一开始想错了方向
一开始的判断，其实非常符合工程师的直觉。
既然数据不对，那大概率是下面这些原因之一：
代理 IP 被针对了。
帐号失效了。
User-Agent 被识别了。
于是我们做了几件非常“熟练”的操作：
更换代理池。
刷新帐号信息。
调整并随机 User-Agent。
结果很直接，也很打脸。
情况没有任何改善。
页面依然可以正常打开，DOM 结构也能抓到，但核心数据依旧是空的。
那一刻我意识到，这可能根本不是反爬问题。
四、真正的问题出在哪
真正的转折点，其实来自一次很原始的排查方式。
我们把爬虫抓到的 HTML 保存下来，又用真实浏览器打开页面，对着 DOM 一点一点比。
最后发现了一个很隐蔽、但致命的变化：
页面结构没有变，但渲染顺序变了。
具体来说：
列表容器的 DOM 很早就生成了。
真正的数据，是在后面通过异步逻辑慢慢注入的。
原来依赖的 load 或 networkidle 事件，已经不能代表“数据已经准备好”。
换句话说，爬虫开始解析页面的时候，页面的“骨架”已经在了，但内容还没填充完成。
我们抓到的不是错误页面，而是一个尚未完成的页面状态。
五、为什么之前一直没暴露
这个问题事后回看，其实并不容易提前发现。
主要有三个原因。
第一，目标站点采用了灰度发布。
新的渲染策略不是一次性上线，而是逐步放量。我们的 IP 恰好慢慢被覆盖进去。
第二，DOM 结构没有变化。
选择器没有失效，代码逻辑看起来完全正常，只是抓到的内容是空的。
第三，监控过于偏工程指标。
我们监控的是成功率、耗时、异常数，却从来没有监控一个问题：
抓到的数据本身还有没有价值。
六、我们是怎么修的
这次问题，没有靠简单地加一个 sleep 解决。
虽然说实话，当时确实很想这么做。
最终我们做了几层调整。
第一，不再单纯相信“页面加载完成”。
不再依赖 load 或 networkidle，而是直接检查关键业务节点是否真正可用。
第二，让爬虫开始“感知页面状态”。
流程从“页面打开就解析”，变成了“页面打开，确认数据状态，再解析”。
第三，升级监控体系。
新增了更偏业务语义的指标，比如字段空值比例、列表长度异常、DOM 结构变化趋势。
目的不是为了报错，而是为了尽早发现那种“程序还在跑，但已经没有产出价值”的状态。
七、核心代码示例
下面这段代码不是炫技，也不是通用模板。
它只是反映了这次事故之后，我们在真实项目中做出的一个关键改变。
import asyncio
from playwright.async_api import async_playwright
async def run():
async with async_playwright() as p:
# 爬虫代理配置
proxy = {
"server": "http://proxy.16yun.cn:12345",
"username": "your_username",
"password": "your_password"
}
browser = await p.chromium.launch(
headless=True,
proxy=proxy
)
context = await browser.new_context(
user_agent=(
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
"AppleWebKit/537.36 (KHTML, like Gecko) "
"Chrome/122.0.0.0 Safari/537.36"
)
)
# 设置 Cookie
await context.add_cookies([
{
"name": "sessionid",
"value": "your_cookie_value",
"domain": ".example.com",
"path": "/"
}
])
page = await context.new_page()
await page.goto("https://example.com", timeout=60000)
# 等待真正有业务意义的数据出现
await page.wait_for_function(
"""
() => {
const items = document.querySelectorAll('.list-item');
return items.length > 0 && items[0].innerText.trim().length > 0;
}
""",
timeout=20000
)
items = await page.query_selector_all(".list-item")
for item in items:
print(await item.inner_text())
await browser.close()
asyncio.run(run())
八、这次事故留下的几条共识
这次复盘之后，我们在团队里形成了几条比较稳定的共识：
现代爬虫的失败，越来越少是因为“被封”。
页面渲染完成，并不等于数据已经就绪。
DOM 能选中，不代表内容一定可信。
sleep 只能缓解问题，不能解决问题。
真正有价值的监控，一定要贴近业务语义。
最后这句话，是我个人在这次事故后的真实感受：
当网页开始“思考”，爬虫就不能再只是一个简单的搬运工了。
