当数据开始“感知页面”

爬虫如何感知页面渲染完成

一次关于渲染时序的真实事故复盘

这次事故,不是被封 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 只能缓解问题,不能解决问题。
真正有价值的监控,一定要贴近业务语义。

最后这句话,是我个人在这次事故后的真实感受:

当网页开始“思考”,爬虫就不能再只是一个简单的搬运工了。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值