networkidle常卡在30秒超时，因后台心跳、埋点、WebSocket等持续请求重置计时器；networkidle0要求0个活跃请求，严格易卡顿，networkidle2允许2个，更实用；推荐改用语义化等待如wait_for_selector或wait_for_function。
networkidle 为什么总卡在 30 秒超时？
它不是坏了，而是被页面“骗”了。Playwright 的 networkidle 默认等待连续 500 毫秒无新请求，但现代页面常有后台心跳、分析埋点、WebSocket 长连接、资源预加载等行为——这些请求不中断用户交互，却让 Playwright 永远重置计时器。
常见诱因包括：
- 页面内嵌的监控 SDK（如 Sentry、Datadog）每 10–30 秒发一次心跳请求
- Google Analytics 或百度统计的
_ga/hm.js轮询 - 前端框架（React/Vue）启用的 devtools 或 HMR 热更新连接（尤其本地开发环境）
- 字体文件（
.woff2）、图标资源（iconfont.css）延迟加载或重试
networkidle0 和 networkidle2 到底差在哪？
networkidle0 表示「最多允许 0 个网络请求处于活跃状态」；networkidle2 表示「最多允许 2 个网络请求处于活跃状态」。注意：这不是“总共只发 0 或 2 个请求”，而是指「当前正在传输中（in-flight）的请求数 ≤ N」。
实际效果差异明显：
立即学习“Python免费学习笔记（深入）”；
-
wait_until='networkidle0'：极其严格，容易卡住，适合干净测试环境或已屏蔽监控脚本的页面 -
wait_until='networkidle2'：更宽松，能容忍字体、favicon、基础埋点等常规请求，是多数生产页面的务实选择 - Playwright Python API 中不支持直接传
'networkidle0'字符串——必须用page.wait_for_load_state('networkidle0')显式调用
比 networkidle 更靠谱的替代方案有哪些？
当页面不可控（比如第三方系统、客户现场环境），硬等 networkidle 就是自找麻烦。优先考虑语义化更强、与业务逻辑对齐的等待方式：
- 等关键内容元素出现：
page.wait_for_selector("main .dashboard-stats", timeout=10000) - 等 JS 状态就绪：
page.wait_for_function("window.APP_READY === true")（需前端配合注入标记） - 等导航提交完成（推荐用于首屏）：
page.goto(url, wait_until="commit")—— 它只等 HTML 解析和初始资源加载，不等后续 fetch，响应更快也更稳定 - 组合等待：先
wait_for_load_state("domcontentloaded")，再wait_for_selector(...)，避免把所有希望押在单一策略上
调试 networkidle 卡住时该看什么？
别猜，直接抓证据。在启动浏览器时开启请求日志，就能一眼看出是谁在“拖后腿”：
page = browser.new_page()
# 启用请求监听
page.on("request", lambda req: print(f"→ {req.method()} {req.url()}"))
page.on("response", lambda res: print(f"← {res.status()} {res.url()}"))
page.goto("https://example.com", wait_until="networkidle")
运行后观察控制台输出：如果最后几行反复出现 GET https://xxx.com/api/heartbeat 或 POST https://stats.example/analytics，就定位到元凶了。此时屏蔽这类域名（page.route("https://*.analytics/*", lambda route: route.abort())）往往比调参更治本。
真正难处理的从来不是 networkidle 本身，而是你默认信任了“网络静默 = 页面可用”这个假设——而现代 Web 应用早已不按这个剧本演了。
