page.goto()串行执行实际并发度为1，因前页未加载完后页无法发起请求；正确做法是在同一BrowserContext下创建多Page，用asyncio.gather()并发调度，并用Semaphore控制并发数。
为什么不能直接用多个 page.goto() 串行执行
串行调用 page.goto() 本质仍是单任务等待：前一个页面没加载完，后一个根本不会发起请求。哪怕开了10个 Page 实例，如果用 await page.goto() 一个个等，实际并发度还是1。Playwright 的异步能力不是靠“开多个页面”自动生效的，而是靠 asyncio.gather() 或 asyncio.create_task() 主动调度。
如何正确创建并并发控制多个标签页
关键不是“开多少页”，而是“让多少页同时跑”。必须在同一个 BrowserContext 下创建多个 Page，再用 asyncio.gather() 统一 await：
-
BrowserContext是轻量级会话容器，复用 Cookie、User-Agent、缓存，比反复launch()浏览器省资源 - 每个
Page对应一个独立标签页，但共享上下文，适合模拟真实用户多标签行为 - 务必用
asyncio.Semaphore控制并发数（比如限制 5–10 个），否则可能触发目标站反爬或本地内存溢出
async def crawl_one_page(page, url):
await page.goto(url, wait_until="networkidle")
return await page.title()
<p>async def main(urls):
async with async_playwright() as p:
browser = await p.chromium.launch()
context = await browser.new_context()</p><h1>限制最多 6 个并发</h1><pre class="brush:php;toolbar:false;"> semaphore = asyncio.Semaphore(6)
async def bounded_crawl(u):
async with semaphore:
page = await context.new_page()
try:
return await crawl_one_page(page, u)
finally:
await page.close()
results = await asyncio.gather(*[bounded_crawl(u) for u in urls])
await browser.close()
return results
page.wait_for_load_state() 和 wait_until 参数怎么选
这两个是高频误用点：page.goto() 的 wait_until 参数决定何时返回，而 page.wait_for_load_state() 是额外等待。多数场景下只用 wait_until="networkidle" 就够了——它表示网络请求基本静默（最后两个请求间隔 > 500ms），比 "load" 更可靠，又比 "domcontentloaded" 更充分。滥用 wait_for_load_state("networkidle") 在已 goto 完成后再调一次，纯属冗余等待。
-
wait_until="commit"：仅等待导航 commit，不等资源，适合测跳转逻辑，不适合数据采集 -
wait_until="domcontentloaded"：HTML 解析完就返回，JS 可能还没执行，价格/评论等动态内容大概率拿不到 -
wait_until="networkidle"：默认超时 30s，对电商/知乎类页面最稳妥；若页面有长轮询请求，可加timeout=60000
为什么关闭 page 比关闭 browser 更关键
很多人以为 browser.close() 就万事大吉，其实不然。Playwright 中 Page 是资源持有者：每个页面独占内存、渲染进程、WebSocket 连接。如果只关 browser 而漏掉 page.close()，未显式关闭的页面会持续占用资源，跑几百个 URL 后极易 OOM。尤其在 asyncio.gather() 场景下，异常退出时 page 更容易泄漏。
- 必须在
try/finally或async with块中确保page.close()执行 - 不要依赖
context.close()自动清理——它只保证上下文级资源释放，不强制终止所有子页面 - 调试时可用
browser.on("disconnected", lambda: print("browser closed"))验证是否真关干净
真实项目里最容易被忽略的，是 Page 生命周期和 asyncio 异常传播的耦合。一个页面加载超时抛出 TimeoutError，若没在 task 内捕获并显式 close()，这个页面就卡在后台继续吃内存——这种问题不会立刻报错，但跑一晚上后内存飙升到 4GB 才暴露。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
