1. 项目概述：为什么需要关注Playwright的性能？

如果你正在用Python Playwright做自动化测试或者数据抓取，大概率遇到过这样的场景：脚本跑得慢吞吞，浏览器启动半天，页面加载卡顿，或者内存占用悄悄飙升直到程序崩溃。这不仅仅是等待时间的问题，在CI/CD流水线里，测试时间就是金钱；在数据抓取任务中，速度就是效率。性能优化，就是从“能用”到“好用”的关键一步。

很多人把Playwright当作一个“开箱即用”的工具，写几行代码能跑起来就满足了。但当你需要处理成百上千个页面，或者将自动化脚本集成到高频执行的流水线中时，那些被忽略的性能细节就会成为瓶颈。优化不仅仅是让脚本“跑得快一点”，更是关乎稳定性、资源利用率和长期维护成本。一个经过优化的Playwright脚本，应该像一台精密的仪器，高效、稳定且可预测。

本指南不会讲那些泛泛而谈的“优化原则”，而是聚焦于Python Playwright在实际使用中，从浏览器启动、页面导航到元素操作、资源管理的全链路性能瓶颈点。我会结合自己踩过的坑和实战经验，拆解每一个环节的优化策略，并提供可以直接“抄作业”的配置和代码片段。无论你是刚入门的新手，还是已经遇到性能瓶颈的老手，都能在这里找到切实可行的解决方案。

2. 核心优化思路与架构设计

性能优化不是盲目地堆砌技巧，而是需要有清晰的思路。对于Playwright这样的浏览器自动化工具，其性能消耗主要分布在几个层面： 浏览器进程本身 、 Playwright与浏览器的通信 、 页面加载与渲染逻辑 以及 我们编写的脚本逻辑 。优化的核心思路就是： 减少不必要的开销，并行化可并行的任务，并精准地等待必要的结果。

2.1 浏览器层：启动与实例管理

这是性能损耗的大头。每次 browser = playwright.chromium.launch() 都意味着启动一个全新的浏览器进程，开销巨大。

核心策略一：复用浏览器上下文（Browser Context） 浏览器上下文可以理解为浏览器的一个独立会话，它共享浏览器进程，但拥有独立的缓存、Cookie和本地存储。创建新上下文的成本远低于启动新浏览器。

# 低效做法：为每个任务启动新浏览器
async def task_one():
    async with async_playwright() as p:
        browser = await p.chromium.launch()
        page = await browser.new_page()
        # ... 操作
        await browser.close()

# 高效做法：启动一次浏览器，创建多个上下文
async with async_playwright() as p:
    browser = await p.chromium.launch()
    async with asyncio.TaskGroup() as tg: # 使用Python 3.11+的TaskGroup
        for i in range(10):
            tg.create_task(run_task(browser, i))
    await browser.close()

async def run_task(browser, task_id):
    context = await browser.new_context() # 创建独立上下文
    page = await context.new_page()
    # ... 独立任务操作
    await context.close() # 任务结束，关闭上下文，释放资源

为什么有效？ 浏览器进程启动涉及初始化V8引擎、加载原生模块等，耗时可能达到1-3秒。而新建上下文通常只需几百毫秒。对于需要隔离Cookie（如测试多用户登录）但又想节省资源的场景，这是首选方案。

核心策略二：无头模式与沙盒 默认情况下，Playwright会启动带有沙盒和可视化界面的浏览器。对于服务器环境，无头模式是必须的。

browser = await p.chromium.launch(headless=True) # 明确使用无头模式

更进一步，可以考虑禁用沙盒以换取微小的启动速度提升，但这会降低安全性，仅适用于完全受控的测试环境。

browser = await p.chromium.launch(headless=True, args=['--no-sandbox', '--disable-setuid-sandbox'])

注意 ：在Docker或某些CI环境中，由于权限问题，可能必须添加 --no-sandbox 参数才能正常运行，但这会引入安全风险，生产环境慎用。

2.2 网络层：拦截与缓存

页面加载慢，很多时候是在等待网络资源。Playwright提供了强大的路由拦截功能，允许我们控制哪些资源需要加载。

优化策略：阻断非必要资源 对于自动化测试或抓取核心内容，图片、样式表、字体、媒体文件通常不是必需的。阻断它们可以极大提升页面加载速度。

async def route_handler(route):
    # 定义需要阻断的资源类型
    blocked_resource_types = ['image', 'stylesheet', 'font', 'media']
    if route.request.resource_type in blocked_resource_types:
        await route.abort()
    else:
        await route.continue_()

await page.route('**/*', route_handler)

实操心得 ：不要一刀切地阻断所有。有些页面逻辑依赖CSS或字体文件来计算布局或触发事件，盲目阻断可能导致元素无法交互或脚本报错。最佳实践是：先全部阻断，如果功能异常，再逐步放行必要的资源类型（如 document , script , xhr ）。对于数据抓取，通常只保留 document 和 xhr 就够了。

利用缓存 ：对于需要重复访问的静态资源，可以尝试启用磁盘缓存。但Playwright的上下文默认使用内存缓存，关闭后即消失。一种高级玩法是，手动管理一个持久化的缓存目录，并在创建浏览器上下文时指定，但这实现起来较为复杂，通常适用于非常特定的爬虫场景。

2.3 执行层：脚本与等待策略

我们写的Python代码如何与浏览器交互，是另一个性能关键点。

策略一：减少不必要的等待，使用精准等待 page.wait_for_timeout(3000) 是性能杀手。它意味着无论页面状态如何，都要死等3秒。

# 差
await page.wait_for_timeout(5000) # 死等5秒
await page.click('button')

# 好
await page.wait_for_selector('button:has-text("Submit")', state='visible') # 等待元素出现且可见
await page.click('button:has-text("Submit")')

Playwright提供了丰富的等待条件： wait_for_selector , wait_for_function , wait_for_event （如 'networkidle' ）等。使用它们可以让脚本在条件满足时立即继续，避免无效等待。

策略二：合并操作与评估（Evaluation） 频繁地在Python和浏览器JavaScript环境之间切换（通过 evaluate ）会有通信开销。尽量将多个操作合并到一次 evaluate 中执行。

# 低效：两次通信
title = await page.title()
url = await page.url()

# 高效：一次通信获取多个值
data = await page.evaluate("""() => {
    return {
        title: document.title,
        url: window.location.href,
        userAgent: navigator.userAgent
    };
}""")
title, url = data['title'], data['url']

策略三：异步并发执行 Python的 asyncio 与Playwright的异步API是天作之合。对于独立的操作，使用 asyncio.gather 并发执行。

# 顺序执行，慢
await page.click('#input1')
await page.fill('#input1', 'text1')
await page.click('#input2')
await page.fill('#input2', 'text2')

# 并发执行，快（假设两个操作互不依赖）
await asyncio.gather(
    page.click('#input1'),
    page.click('#input2')
)
await asyncio.gather(
    page.fill('#input1', 'text1'),
    page.fill('#input2', 'text2')
)

但要注意，并发操作同一个页面元素可能导致竞争条件，需确保逻辑正确。

3. 关键配置参数详解与调优

Playwright的 launch 和 new_context 方法提供了大量参数，理解并调优它们对性能有立竿见影的效果。

3.1 浏览器启动参数调优

browser = await p.chromium.launch(
    headless=True, # 基础：无头模式
    args=[
        '--disable-blink-features=AutomationControlled', # 防止被检测为自动化工具
        '--disable-dev-shm-usage', # 解决Docker中共享内存问题，避免崩溃
        '--disable-accelerated-2d-canvas', # 禁用GPU加速，提升无头模式稳定性
        '--disable-gpu', # 同上，在无头模式下禁用GPU
        '--no-first-run', # 跳过首次运行向导
        '--no-zygote', # 禁用Zygote进程，可能提升启动速度（Linux）
        '--single-process', # 单进程模式（实验性），内存占用更少，但稳定性可能下降，仅用于简单任务
        f'--window-size={width},{height}' # 设置初始窗口大小，避免后续调整
    ],
    # 忽略默认的`--disable-background-networking`等参数，它们已被Playwright内部设置
)

参数解析 ：

• --disable-dev-shm-usage ：在Docker等受限环境中，/dev/shm（共享内存）可能太小，导致Chrome崩溃。添加此参数使用临时目录替代。
• --single-process ：这是一个高风险高回报的参数。它将渲染器、GPU等进程合并到浏览器主进程，能显著减少内存占用（有时可达30%）。但一个标签页崩溃会导致整个浏览器崩溃，且某些复杂页面可能渲染异常。 仅推荐用于执行简单、稳定任务的爬虫脚本 。

3.2 浏览器上下文配置优化

浏览器上下文是性能调优的核心载体。

context = await browser.new_context(
    viewport={'width': 1920, 'height': 1080},
    user_agent='你的自定义UA',
    ignore_https_errors=True, # 忽略HTTPS证书错误，加快对某些测试环境的访问
    java_script_enabled=True, # 默认开启，如无需JS可关闭以加速
    bypass_csp=True, # 绕过内容安全策略，方便测试但可能影响安全性
    # 关键性能参数：
    locale='zh-CN', # 设置语言环境，避免加载额外语言包
    timezone_id='Asia/Shanghai', # 设置时区
    permissions=['geolocation'], # 明确授予所需权限，避免弹窗等待
    # 资源控制：
    extra_http_headers={'Accept-Language': 'zh-CN,zh;q=0.9'}, # 设置请求头，可能影响CDN分发
)

特别关注 locale 和 timezone_id ：这两个参数看似无关紧要，实则影响深远。如果未指定，浏览器会使用系统默认或一个通用设置，可能导致页面加载针对特定区域的语言包、时间格式库，甚至影响某些基于区域的内容渲染。明确指定可以避免这些潜在的网络请求和计算开销。

3.3 页面导航与加载策略

page.goto() 是主要的性能瓶颈点之一。其 wait_until 参数决定了何时认为导航“完成”。

# 不同策略的等待时机
await page.goto(url, wait_until='domcontentloaded') # DOM解析完成即继续，最快，但可能JS未执行。
await page.goto(url, wait_until='load') # 页面load事件触发，资源基本加载，较平衡。
await page.goto(url, wait_until='networkidle') # 网络空闲（约500ms无请求），最慢但最“稳”。
await page.goto(url, wait_until='commit') # 接收到网络响应就开始，极快，但DOM都不可用。

选择策略 ：

• 数据抓取 ：如果目标数据在初始HTML中，或你打算自己触发AJAX，用 'domcontentloaded' 或 'commit' 然后配合自定义等待。
• 自动化测试 ：需要页面完全可交互，推荐 'load' 或 'networkidle' 。对于单页应用（SPA）， 'networkidle' 更可靠。
• 终极速度 ：使用 'commit' ，然后立刻用 page.wait_for_selector 等待你关心的特定元素出现。这比等待整个页面加载完毕要快得多。

4. 实战：构建一个高性能的并行爬虫框架

让我们将上述策略整合，构建一个用于数据抓取的高性能框架。这个框架需要处理大量URL，并高效地提取数据。

4.1 架构设计

我们将采用“生产者-消费者”模型。一个主协程负责分发URL（生产者），多个工作协程负责启动浏览器上下文、处理页面（消费者）。使用信号量（Semaphore）控制并发度，避免同时打开过多浏览器上下文导致内存爆炸。

import asyncio
import logging
from typing import List
from playwright.async_api import async_playwright, Browser, BrowserContext

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

class HighPerfCrawler:
    def __init__(self, max_concurrency: int = 5, headless: bool = True):
        self.max_concurrency = max_concurrency
        self.headless = headless
        self.semaphore = asyncio.Semaphore(max_concurrency)

    async def crawl_urls(self, urls: List[str]):
        """主爬取入口"""
        async with async_playwright() as p:
            # 启动一个共享的浏览器实例
            browser = await p.chromium.launch(
                headless=self.headless,
                args=['--disable-dev-shm-usage', '--no-sandbox']
            )
            logger.info("浏览器启动成功")

            # 创建任务列表
            tasks = []
            for url in urls:
                task = asyncio.create_task(self._worker(browser, url))
                tasks.append(task)

            # 等待所有任务完成
            results = await asyncio.gather(*tasks, return_exceptions=True)
            await browser.close()
            return self._process_results(results)

    async def _worker(self, browser: Browser, url: str):
        """单个URL的处理工作者"""
        async with self.semaphore: # 控制并发数
            context = await browser.new_context(
                viewport={'width': 1280, 'height': 800},
                locale='zh-CN',
                ignore_https_errors=True,
                # 拦截非必要资源
            )
            page = await context.new_page()

            # 设置路由拦截：阻断图片、样式、字体、媒体
            await page.route('**/*', self._block_assets)
            
            try:
                logger.debug(f"开始处理: {url}")
                # 快速导航，只等待DOM解析
                await page.goto(url, wait_until='domcontentloaded', timeout=30000)
                
                # 可选：等待特定关键元素出现，比networkidle更快
                # await page.wait_for_selector('article', state='attached', timeout=10000)
                
                # 提取数据
                data = await self._extract_data(page)
                logger.info(f"成功处理: {url}")
                return {'url': url, 'data': data, 'success': True}
            except Exception as e:
                logger.error(f"处理失败 {url}: {e}")
                return {'url': url, 'error': str(e), 'success': False}
            finally:
                # 无论如何，关闭上下文释放资源
                await context.close()

    async def _block_assets(self, route):
        """路由处理器：阻断非核心资源"""
        resource_type = route.request.resource_type
        if resource_type in ['image', 'stylesheet', 'font', 'media']:
            await route.abort()
        else:
            await route.continue_()

    async def _extract_data(self, page):
        """具体的数据提取逻辑，需要根据目标网站实现"""
        # 示例：提取标题和首个段落
        data = await page.evaluate("""() => {
            const title = document.title;
            const firstPara = document.querySelector('p')?.innerText || '';
            return { title, firstPara };
        }""")
        return data

    def _process_results(self, results):
        """处理并汇总结果"""
        successful = [r for r in results if isinstance(r, dict) and r.get('success')]
        failed = [r for r in results if isinstance(r, dict) and not r.get('success')]
        errors = [r for r in results if isinstance(r, Exception)]
        return {
            'total': len(results),
            'success': len(successful),
            'failed': len(failed),
            'errors': len(errors),
            'sample_data': successful[:3] if successful else []
        }

# 使用示例
async def main():
    urls = ['https://example.com/page1', 'https://example.com/page2'] # 你的URL列表
    crawler = HighPerfCrawler(max_concurrency=3, headless=True)
    results = await crawler.crawl_urls(urls)
    print(results)

if __name__ == '__main__':
    asyncio.run(main())

4.2 性能对比与参数调整

为了展示优化效果，我们可以做一个简单的对比实验。假设有100个相似的新闻页面需要抓取标题。

优化项	配置A (未优化)	配置B (基础优化)	配置C (激进优化)
浏览器启动	每个任务独立启动	全局启动一个，复用上下文	同B
并发数	1 (顺序执行)	5	10
资源拦截	无	阻断图片、字体、媒体	同B
导航等待	wait_until='networkidle'	wait_until='domcontentloaded'	wait_until='commit' + 等待特定元素
预期耗时	~ 100 * 3s = 300s	~ (100/5) * 1.5s = 30s	~ (100/10) * 0.8s = 8s

实测心得 ：配置C的速度最快，但对网站稳定性要求最高。如果目标网站响应慢或元素选择器不可靠，失败率会上升。 生产环境中，我通常从配置B开始，稳定后再根据实际情况向C调整。 并发数 ( max_concurrency ) 不是越大越好，它受限于机器内存和网络带宽。通常设置为CPU核心数的2-3倍是个不错的起点，需要通过压测找到甜蜜点。

5. 内存泄漏排查与防治指南

Playwright脚本长时间运行后内存不断增长，直至崩溃，这是最常见也最头疼的问题之一。内存泄漏的根源通常是 对象未被正确释放 。

5.1 常见泄漏点与解决方案

泄漏点1：未关闭的页面（Page）和上下文（Context） 这是最经典的泄漏。每个Page和Context都会持有相当多的内存。

# 错误示例：创建了页面但没关闭
async def leaky_function():
    context = await browser.new_context()
    page = await context.new_page()
    await page.goto('...')
    # 函数结束，但page和context的引用还在，未被垃圾回收（可能）
    # 即使外部没有引用，异步环境下垃圾回收时机不确定，显式关闭是最佳实践。

# 正确做法：使用async with确保关闭
async def safe_function():
    async with await browser.new_context() as context:
        async with await context.new_page() as page:
            await page.goto('...')
            # ... 操作
        # 退出with块，page和context会自动关闭

如果不能用 async with ，务必在 finally 块中手动关闭：

context = None
page = None
try:
    context = await browser.new_context()
    page = await context.new_page()
    await page.goto('...')
finally:
    if page:
        await page.close()
    if context:
        await context.close()

泄漏点2：事件监听器（Event Listeners）未移除 给page或context添加了事件监听器，但在其生命周期结束后没有移除。

page.on('request', lambda request: print(request.url))
# ... 长时间运行后，即使page关闭，这个匿名函数可能还被引用着。

解决方案 ：如果添加了监听器，在关闭前尽量移除。或者，更简单的办法是，让持有监听器的page/context对象本身被正确关闭和销毁，大多数情况下其关联的监听器也会被清理。

泄漏点3：大型JavaScript对象驻留 在 page.evaluate 中创建了巨大的数组或对象，并返回到Python端。如果这个Python变量长期存在，会导致其引用的JS对象也无法释放。

huge_data = await page.evaluate("""() => {
    // 在浏览器环境创建一个非常大的对象
    return Array.from({length: 1000000}, (_, i) => ({id: i, data: 'x'.repeat(100)}));
}""")
# `huge_data` 现在是一个包含100万个字典的Python列表，占用大量内存。

解决方案 ：流式处理数据。不要一次性把所有数据拉回内存。如果可能，在浏览器端进行过滤、聚合，只返回摘要信息。或者，分批处理数据，处理完一批后，显式删除变量 del huge_data ，并可能触发垃圾回收 import gc; gc.collect() （谨慎使用）。

5.2 内存监控与调试技巧

使用内置工具 ：Playwright Python本身不提供详细的内存监控，但你可以通过操作系统的工具（如 top , htop , ps ）观察进程内存（RSS）变化。

在代码中采样监控 ：

import psutil
import os
import asyncio

def get_current_memory_mb():
    """获取当前进程内存使用(MB)"""
    process = psutil.Process(os.getpid())
    return process.memory_info().rss / 1024 / 1024

async def long_running_task():
    start_mem = get_current_memory_mb()
    # ... 执行一段Playwright操作 ...
    await asyncio.sleep(10)
    end_mem = get_current_memory_mb()
    logger.info(f"内存变化: {end_mem - start_mem:.2f} MB")

定期执行这个检查，如果发现内存持续增长且不回落，就说明存在泄漏。

使用Chrome DevTools Protocol (CDP)进行堆快照（高级） ：Playwright可以通过CDP会话连接到浏览器，执行更底层的命令，包括获取堆内存快照。但这需要较深的Chrome调试知识。

# 通过CDP触发垃圾回收（不保证立即生效，但可以辅助测试）
client = await page.context.new_cdp_session(page)
await client.send('HeapProfiler.collectGarbage')

一个实用的排查流程 ：

1. 简化复现 ：写一个最小的、可重复的脚本，能稳定重现内存增长。
2. 二分法定位 ：注释掉一半代码，看内存是否还增长。不断缩小范围，定位到引发泄漏的特定操作（如打开特定页面、执行某段JS）。
3. 检查对象生命周期 ：重点检查Page, Context, JSHandle对象的创建和销毁是否成对出现。
4. 怀疑第三方网站 ：有些网站本身的JS可能存在内存泄漏，即使你关闭了页面，浏览器的渲染进程可能仍未完全释放。尝试用 about:blank 页面替代目标网站，看是否还泄漏。

6. 高级技巧与场景化优化

6.1 针对单页应用（SPA）的优化

SPA页面导航不刷新，传统的 page.goto 和 wait_until='networkidle' 可能不奏效。

策略：监听特定网络请求或DOM变化

# 方法1：等待某个特定的API请求完成（假设点击按钮后触发fetch到 /api/data）
async with page.expect_response('**/api/data') as response_info:
    await page.click('#load-data-button')
response = await response_info.value
data = await response.json()

# 方法2：等待某个元素出现或状态改变
await page.click('#next-page')
await page.wait_for_selector('.new-page-content', state='visible')
# 或者等待旧的元素消失
await page.wait_for_selector('.loading-spinner', state='hidden')

6.2 文件下载优化

Playwright处理下载默认会弹出一个保存对话框。我们需要抑制对话框并直接获取文件。

# 设置下载路径，并监听下载事件
async with page.expect_download() as download_info:
    await page.click('a#download-link') # 触发下载的点击操作
download = await download_info.value
# 指定保存路径
save_path = f'./downloads/{download.suggested_filename}'
await download.save_as(save_path)

性能要点 ：下载大文件时，避免阻塞主线程。可以将下载操作放在单独的异步任务中，或者使用 download.path() 获取临时文件路径后，在后台线程中进行文件处理。

6.3 与异步框架集成（如FastAPI, Django Channels）

在Web服务器中使用Playwright需要特别注意： 绝对不能在每个请求中启动/关闭浏览器 。这会导致服务器瞬间崩溃。

推荐模式：浏览器池（Browser Pool） 维护一个全局的、可重用的浏览器实例池。

# 简化示例：全局浏览器实例
from contextlib import asynccontextmanager
from fastapi import FastAPI
import asyncio
from playwright.async_api import async_playwright, Browser

_browser: Browser | None = None

async def get_browser() -> Browser:
    global _browser
    if _browser is None:
        pw = await async_playwright().start()
        _browser = await pw.chromium.launch(headless=True, args=['--disable-dev-shm-usage'])
    return _browser

@app.get("/screenshot")
async def take_screenshot(url: str):
    browser = await get_browser()
    async with await browser.new_context() as context:
        async with await context.new_page() as page:
            await page.goto(url, wait_until='networkidle')
            screenshot = await page.screenshot(full_page=True)
    return StreamingResponse(io.BytesIO(screenshot), media_type="image/png")

# 在应用关闭时清理浏览器
@asynccontextmanager
async def lifespan(app: FastAPI):
    # 启动时...
    yield
    # 关闭时
    global _browser
    if _browser:
        await _browser.close()

关键点 ：使用 new_context() 为每个请求（或每个用户会话）创建独立的上下文，实现隔离。上下文创建和销毁的成本很低，但共享浏览器进程带来了巨大的性能优势。同时，你需要实现健康检查，在浏览器崩溃时能自动重启实例。

6.4 性能度量与基准测试

优化前后，需要有数据支撑。Playwright提供了性能测量接口。

# 方法1：使用`page.metrics()`获取性能计数器
await page.goto('https://example.com')
metrics = await page.metrics()
print(f"JS堆大小: {metrics['JSHeapUsedSize']}")
print(f"文档数量: {metrics['Documents']}")
print(f"节点数量: {metrics['Nodes']}")

# 方法2：使用`page.evaluate`执行Performance API
performance_timing = await page.evaluate("""() => JSON.stringify(window.performance.timing)""")
# 解析计算白屏时间、加载完成时间等

# 方法3：追踪（Tracing）生成详细性能报告
await context.tracing.start(screenshots=True, snapshots=True)
await page.goto(url)
await context.tracing.stop(path='trace.zip')
# 用 `playwright show-trace trace.zip` 命令可视化分析

建立一个简单的基准测试脚本，在关键优化前后运行，记录总执行时间、内存峰值、网络请求数量等指标，用数据证明优化的有效性。

7. 疑难杂症与排查清单

即使遵循了所有最佳实践，你仍可能遇到奇怪的问题。下面是一个快速排查清单。

问题现象	可能原因	排查步骤与解决方案
脚本运行越来越慢	内存泄漏；页面缓存积累；操作系统资源不足。	1. 监控内存使用（见5.2节）。2. 检查Page/Context是否关闭。3. 尝试定期重启浏览器实例。
page.goto 超时	网络问题；页面JS执行死循环；目标网站有反爬。	1. 增加 timeout 参数。2. 使用 wait_until='domcontentloaded' 而非 'networkidle' 。3. 检查是否被屏蔽（尝试手动访问）。4. 添加 user_agent 和 extra_http_headers 。
元素找不到 ( wait_for_selector 超时)	选择器写错；元素在iframe内；页面未加载完；元素被动态生成。	1. 使用Playwright DevTools ( await page.pause() ) 检查元素。2. 检查是否有iframe，用 frame.locator() 。3. 确保等待条件正确（如 state='visible' ）。4. 尝试更通用的选择器或文本匹配。
操作（如click）无效	元素被遮挡；元素不可交互；需要hover等前置操作。	1. 使用 page.click(selector, force=True) 强制点击（谨慎）。2. 先 await page.hover(selector) 。3. 使用 page.locator(selector).dispatch_event('click') 模拟事件。
在Docker/CI中运行失败	缺少浏览器依赖；共享内存不足；无头模式渲染问题。	1. 确保Docker镜像包含Playwright所需依赖 ( mcr.microsoft.com/playwright/python )。2. 添加启动参数 --disable-dev-shm-usage 。3. 尝试设置环境变量 DISPLAY=:99 并启动一个虚拟X服务器（对于需要非无头模式的情况）。
被网站检测为自动化工具	浏览器指纹被识别。	1. 使用 context.new_page() 时传入 user_agent 。2. 尝试添加 args=['--disable-blink-features=AutomationControlled'] 。3. 使用 playwright-stealth 等第三方插件（注意兼容性）。4. 终极方案：手动管理用户数据目录，使用真实用户配置文件。

最后的心得 ：性能优化是一个持续迭代和权衡的过程。没有银弹，最好的配置取决于你的具体场景（是测试还是爬虫？目标网站是快是慢？机器资源是充裕还是紧张？）。我的建议是，从默认配置开始，记录基线性能。然后，一次只应用一项优化，并测量其效果。这样你就能清楚地知道，每一项调整带来了多少收益，又引入了什么风险。保持脚本的简洁和可维护性，有时比极致的性能更重要。当你遇到一个棘手的性能问题时，不妨回到Playwright的官方文档和社区，那里有无数开发者分享的经验，很可能已经有人解决了你正在面对的难题。