Playwright Python中设置全局超时用page.set_default_timeout()，该方法为当前page实例设置后续所有等待、点击、填充等操作的默认超时（毫秒），如page.set_default_timeout(5000)。
Playwright Python中设置全局超时用哪个参数？
Playwright Python客户端不提供真正意义上的“全局超时”配置项，playwright.sync_api.sync_playwright() 或 playwright.async_api.async_playwright() 本身不接受 timeout 参数。所有超时控制必须落在具体操作上，最常用的是通过 page、locator、frame 等对象的 timeout 参数显式传入，或统一设置 playwright 实例的默认超时。
实际可行的方式是：在启动浏览器前，通过 playwright 对象的 chromium.launch()（或其他 browser）调用时传入 timeout 控制启动耗时；对页面级行为，则靠 page.set_default_timeout() 设置后续所有等待/点击/填充等操作的默认超时（单位毫秒）：
from playwright.sync_api import sync_playwright <p>with sync_playwright() as p: browser = p.chromium.launch(timeout=10000) # 启动浏览器超时 page = browser.new_page() page.set_default_timeout(5000) # 此后 locator.click(), page.wait_for_load_state() 等都默认用 5s</p>
注意：set_default_timeout() 只影响当前 page 实例，不是进程级或模块级全局；多个 page 需各自设置。
重试与重连机制 Playwright 原生支持吗？
Playwright 本身**没有内置重试或自动重连逻辑**——它不会在 page.goto() 失败后自动重试 URL，也不会在网络断开时尝试重建 browser 或 page。所谓“重试”，必须由用户代码显式实现。
常见重试场景和做法：
-
page.goto()因网络抖动失败：用try/except捕获TimeoutError或Error，配合time.sleep()和循环重试 - 元素查找失败（如
locator.click()找不到）：不建议盲目重试，应优先用locator.wait_for(state="visible", timeout=...)确保就绪；若仍需重试，可封装带计数的点击函数 - 整个 browser 进程崩溃（如 Chromium OOM）：无法自动恢复，只能重建
browser实例，但要注意旧 page 引用会失效，需重新new_page()
示例：带重试的导航
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
for _ in range(3):
try:
page.goto("https://example.com", timeout=8000)
break
except Exception as e:
if "net::ERR_CONNECTION_REFUSED" in str(e):
print("Connection failed, retrying...")
time.sleep(1)
else:
raise
为什么 set_default_timeout 不影响 browser.launch()？
因为 browser.launch() 是 playwright 进程与浏览器二进制之间的底层通信，超时由 subprocess 启动逻辑控制，而 set_default_timeout() 仅作用于已建立连接后的 page API 调用。两者生命周期和通信层级完全不同。
容易混淆的点：
-
playwright.chromium.launch(timeout=...)：控制启动浏览器进程的等待上限（默认 30s），超时抛Error -
page.goto(timeout=...)或page.set_default_timeout(...)：控制页面内 DOM 加载、资源请求、脚本执行等前端行为的等待上限 -
page.wait_for_timeout(ms)：是硬性 sleep，不检查状态，不受set_default_timeout()影响
如果你在 CI 环境中频繁遇到 launch 超时，更可能是环境问题（如缺少沙箱、共享内存不足），而非 timeout 值设小了。
真实项目里最容易被忽略的超时陷阱
很多团队只设了 page.set_default_timeout()，却忘了几个关键位置依然使用默认 30s，导致偶发长卡顿：
-
browser.close()没有 timeout 参数，关闭缓慢时会阻塞整个上下文退出 -
page.screenshot()默认无超时，大页面渲染可能卡住几十秒；务必显式加timeout=10000 -
page.route()中的回调函数如果包含同步阻塞操作（如读文件、调本地 API），会拖慢整个页面加载，且不触发任何 timeout 报错 - 使用
page.evaluate()执行复杂 JS 时，JS 内部死循环不会被 Python 层 timeout 中断，需靠 JS 侧加setTimeout或AbortController配合
真正稳定的 Playwright 脚本，不是靠一个“全局开关”，而是每个可能挂起的操作都明确声明 timeout，并对不可控环节（如截图、evaluate）做兜底防护。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
