别再死记硬背async/await了！用Playwright+Python写自动化脚本，这3个坑我帮你踩过了

第一次用Playwright写自动化测试脚本时，我对着文档里的async/await关键字发呆了半小时。明明照着示例代码敲了一遍，运行时却总是报错。后来才发现，问题出在我对Python异步编程的理解太肤浅——以为加上await就能自动实现并行，结果连最基本的执行顺序都控制不了。

如果你也在Playwright的异步世界里跌跌撞撞，这篇文章就是为你准备的。我会用三个真实踩过的坑，带你避开新手最常见的误区。这些经验都是用深夜调试的咖啡换来的，保证你看完就能写出更健壮的自动化脚本。

1. 同步上下文中的await陷阱：为什么你的脚本突然崩溃

去年给电商项目写爬虫时，我遇到了一个诡异的问题：在Jupyter Notebook里运行完美的Playwright脚本，移植到Django项目里就报错。错误信息显示"SyntaxError: 'await' outside async function"，可明明代码里到处都是async def。

1.1 同步与异步的边界混淆

问题出在我混用了同步和异步上下文。看这段典型错误代码：

from playwright.sync_api import sync_playwright def test_login(): with sync_playwright() as p: browser = p.chromium.launch() page = browser.new_page() await page.goto("https://example.com") # 这里会报错！

关键问题：sync_playwright()创建的是同步上下文，而await只能在异步函数中使用。这种错误在新手中特别常见，因为Playwright的文档同时提供了同步和异步两种API。

1.2 两种修正方案对比

方案A：统一使用同步API（适合简单脚本）

from playwright.sync_api import sync_playwright def test_login(): with sync_playwright() as p: browser = p.chromium.launch() page = browser.new_page() page.goto("https://example.com") # 去掉await

方案B：全异步写法（推荐复杂场景）

from playwright.async_api import async_playwright import asyncio async def test_login(): async with async_playwright() as p: browser = await p.chromium.launch() page = await browser.new_page() await page.goto("https://example.com") asyncio.run(test_login())

提示：如果你在Django等同步框架中调用异步代码，需要使用sync_to_async装饰器转换。但最佳实践是保持整个调用链的一致性。

2. 时间控制的误区：time.sleep如何毁掉你的并行效率

在调试一个需要等待页面加载的脚本时，我习惯性地写下了time.sleep(5)。结果发现整个脚本的执行时间比预期长了3倍——异步的优势完全消失了。

2.1 阻塞式睡眠的代价

看这个对比实验：

import time import asyncio async def demo_blocking(): print("开始任务") time.sleep(3) # 同步阻塞 print("结束任务") async def demo_non_blocking(): print("开始任务") await asyncio.sleep(3) # 异步挂起 print("结束任务")

运行两个函数的区别：

2.2 Playwright中的正确等待方式

在自动化测试中，硬性等待（无论time还是asyncio.sleep）都是次优选择。Playwright提供了更智能的等待机制：

await page.goto(url, wait_until="networkidle") # 等待网络空闲 await page.wait_for_selector("#submit-btn") # 等待元素出现 await page.wait_for_function("window.readyState === 'complete'") # 自定义条件

这些方法比固定时长等待更可靠，还能自动适应不同网络环境。我在实际项目中测得，用智能等待平均能节省40%的执行时间。

3. 事件循环管理：为什么你的async代码有时不执行

最让我抓狂的一次调试经历是：明明所有语法都正确，但异步函数就是不被执行。最后发现是因为事件循环没有正确启动。

3.1 事件循环的三种启动方式

错误示范（新手常见）：

async def scrape_data(): # ...Playwright操作... scrape_data() # 这样调用不会执行！

正确方法一（Python 3.7+推荐）：

asyncio.run(scrape_data()) # 创建并运行新事件循环

正确方法二（需要精细控制时）：

loop = asyncio.get_event_loop() try: loop.run_until_complete(scrape_data()) finally: loop.close()

正确方法三（在已有事件循环中运行）：

async def main(): await scrape_data() await other_task() asyncio.run(main())

3.2 Playwright与事件循环的配合

当使用Playwright的异步API时，特别要注意浏览器启动和关闭的时机。这是我总结的最佳实践：

async def run_playwright(): async with async_playwright() as p: browser = await p.chromium.launch() try: page = await browser.new_page() # 主要操作逻辑... finally: await browser.close() # 确保浏览器被关闭 # 在Jupyter等特殊环境中可能需要这样调用 import nest_asyncio nest_asyncio.apply() asyncio.run(run_playwright())

注意：如果在Jupyter Notebook中运行遇到事件循环错误，需要先安装nest-asyncio包。这是因为Jupyter本身已经运行了一个事件循环。

4. 实战：构建健壮的异步测试框架

掌握了这些避坑技巧后，我们可以设计更可靠的测试架构。以下是我在多个项目中验证过的模式：

4.1 分层设计架构

tests/ ├── __init__.py ├── conftest.py # 全局fixture ├── fixtures/ # 设备管理 │ ├── browser.py # 浏览器生命周期 │ └── pages.py # 页面对象管理 ├── utils/ │ └── async_utils.py # 异步工具函数 └── test_*.py # 实际测试用例

关键文件fixtures/browser.py示例：

import pytest from playwright.async_api import async_playwright @pytest.fixture(scope="session") async def browser(): async with async_playwright() as p: browser = await p.chromium.launch(headless=False) yield browser await browser.close()

4.2 错误处理模板

async def safe_click(element, timeout=5000): try: await element.click(timeout=timeout) except Exception as e: await page.screenshot(path="error.png") raise AssertionError(f"点击元素失败: {e}") from e

4.3 性能优化技巧

• 并行执行：使用asyncio.gather同时运行多个测试
• 上下文复用：通过fixture共享浏览器实例
• 智能等待：结合Playwright的auto-waiting机制
• 资源监控：用browser.contexts跟踪内存泄漏

async def run_tests_parallel(): results = await asyncio.gather( test_login(), test_search(), test_checkout(), return_exceptions=True ) for r in results: if isinstance(r, Exception): print(f"测试失败: {r}")

第一次完整跑通这套架构时，我们的测试套件执行时间从原来的12分钟降到了3分钟。更棒的是，那些偶发的超时错误几乎消失了——因为正确的异步处理让资源竞争变得可控。