怎样利用Python和Playwright实现浏览器多页面的异步并发操作？-Python教程-PHP中文网

不能直接对多个page.goto()调用asyncio.gather()，因为page实例必须先通过await context.new_page()创建完成，否则会抛出attributeerror或timeouterror；正确做法是三阶段分离：先批量创建页面、再批量导航、最后批量读取结果。

怎样利用python和playwright实现浏览器多页面的异步并发操作？

page.goto() 的 wait_until 参数选错、asyncio.gather() 用法不当、在同步上下文中混用异步逻辑——这三类问题占了实际并发脚本失败的 80% 以上。直接上手写 asyncio.gather(*[page.goto(u) for u in urls]) 看似简洁，但多数人会掉进资源泄漏或状态冲突的坑里。

为什么不能直接对多个 `page.goto()` 调用 `asyncio.gather()`？

因为 page.goto() 需要页面实例已创建且处于可用状态；而如果页面还没 await browser.new_page() 完就扔进 gather，会抛出 AttributeError: 'coroutine' object has no attribute 'goto' 或更隐蔽的 TimeoutError。

必须先确保每个 page 实例已成功创建（即 await context.new_page() 已完成）
page.goto() 本身是协程，不能提前“打包”进列表再统一 await —— 必须保证调用链完整
推荐结构：先批量创建页面 → 再批量导航 → 最后批量读取结果，三阶段分离

`browser.new_context()` 和 `context.new_page()` 怎么配对才安全？

一个 browser 可以有多个 context，一个 context 可以有多个 page。并发时若所有页面共用同一个 context，它们共享 cookies、localStorage 和网络拦截规则，适合模拟同一用户多标签行为；若需要完全隔离（如不同账号、不同 UA），就得为每个任务新建 context。

Comet AI 浏览器

下载 Comet AI 浏览器，体验由 Perplexity AI 驱动的革命性上网方式。内置 AI 助手可实时总结网页、跨标签页对比信息、自动执行任务。告别繁琐操作，让 AI 成为你的浏览副驾，大幅提升研究与工作效率。支持 Windows、macOS、Android 和 iOS。

下载

高并发场景下，context 创建开销比 page 大得多，别为每个 URL 新建 context
默认情况下，browser.new_context() 是线程/协程安全的，但 context 本身不是跨协程共享资源 —— 每个协程应持有自己创建的 page，不要传递 page 实例给其他协程
务必在 finally 或 async with 中关闭 page，否则未关闭页面会持续占用内存和 socket 连接

`wait_until="networkidle"` 到底要不要加？

加，但只加一次，且只加在 page.goto() 上。这是最常被重复使用的错误：有人在 goto 后又显式调用 page.wait_for_load_state("networkidle")，导致多等 500ms 以上。

wait_until="networkidle" 表示最后两个网络请求间隔 > 500ms，对绝大多数 SPA 页面足够可靠
避免用 "load" —— 它只等 DOMContentLoaded + load 事件，JS 可能还没初始化完
绝对不要用 "commit" 做页面采集 —— 它只等导航 commit，连 HTML 都没开始解析
如果目标页面有长轮询或心跳请求（如 WebSocket 连接），"networkidle" 会永远等下去，此时应改用 wait_until="domcontentloaded" + 显式等待关键元素

并发数设多少才不翻车？

不是越多越好。Playwright 的并发瓶颈不在 Python 层，而在浏览器进程的内存与 socket 资源。实测 Chromium 在 6–8 个并发页面时 CPU 和内存增长平缓；超过 12 个后，页面加载失败率明显上升，尤其在 Windows 下。

用 asyncio.Semaphore(6) 控制最大并发数，比无限制 gather 稳定得多
别在 launch() 里加 headless=False 跑高并发 —— GUI 渲染会吃光 GPU 内存
如果跑在 CI 或低配服务器上，建议把 semaphore 降到 3–4，并启用 --no-sandbox 和 --disable-setuid-sandbox 启动参数

真正容易被忽略的点是：每个 page 关闭前，是否清除了监听器、定时器或未 resolve 的 Promise。Playwright 不会自动回收这些 JS 层残留，积累多了会导致页面响应变慢甚至崩溃。写 finally: await page.close() 是底线，但更稳妥的做法是在 page 上挂载清理钩子，比如 page.on("close", ...) 或用 page.evaluate("() => { clearInterval(window.timer); }") 主动释放。