Playwright 的 page.goto() 默认超时是 30 秒，由全局 timeout 参数控制，可通过调用传参、页面配置或浏览器上下文配置覆盖，推荐优先在调用处显式指定。
Playwright 的 page.goto() 默认超时是多少
Playwright 的 page.goto()（以及 page.click()、page.fill() 等多数动作）默认超时是 30 秒。这个值由全局的 timeout 参数控制，不是硬编码在源码里，而是可覆盖的。如果你遇到 TimeoutError: page.goto: Navigation timeout of 30000 ms exceeded，说明页面加载或重定向卡在了这一步。
三种改法：按优先级从高到低排列
修改超时有三个层级，生效优先级依次为：调用时传参 > 页面实例配置 > 浏览器上下文配置。推荐优先在具体调用处显式指定，避免影响其他操作。
- 最常用、最安全：直接在
page.goto()中加timeout参数，单位毫秒：await page.goto("https://example.com", timeout=60000) - 若整页操作都需更长等待（比如测试一个慢后台系统），可在创建
page后设置其默认超时：page.set_default_timeout(60000)
注意：该设置只对当前page实例后续动作生效，不影响其他页面 - 不推荐但存在：通过
browser.new_context()设置javaScriptEnabled以外的参数——它不接受timeout；真正能全局控超时的是启动时传入playwright.launch(..., timeout=60000)，但这只控制浏览器启动本身，**不控制导航超时**
为什么设太高可能掩盖真实问题
把 timeout 改成 120000 甚至 300000 并不能解决根本问题，反而会让失败更难定位。常见陷阱包括：
- 页面实际已崩溃或白屏，但 Playwright 还在等“导航完成”信号（比如没触发
load或networkidle） - 你用了
wait_until="networkidle"却没意识到某些资源（如埋点脚本、广告 iframe）永远不 idle - 服务端返回了 200 但 HTML 是空的或含严重 JS 错误，Playwright 不校验内容有效性，只等生命周期事件
建议搭配 wait_until="commit"（仅等待导航 commit，最快）或显式 page.wait_for_load_state("domcontentloaded") 来缩小等待范围，再辅以自定义断言（如检查 page.query_selector("main") 是否存在）。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
立即学习“Python免费学习笔记（深入）”；
异步环境下的 timeout 陷阱
在 asyncio 应用中，Playwright 的 timeout 是独立于 Python 的 asyncio.timeout() 的。如果你在外层套了 async with asyncio.timeout(10):，而 page.goto(timeout=60000)，最终会以更短的那个为准（即 10 秒）。反过来，如果 Playwright 内部 timeout 更短，外层 asyncio timeout 就不会触发。
真正容易被忽略的是：Playwright 的 timeout 计时从调用开始，**包含 DNS 查询、TCP 握手、TLS 协商、重定向跳转、HTML 解析、JS 执行全过程**。它不像 requests 那样区分 connect/read timeout。所以网络不稳定时，哪怕服务器响应快，也可能因 DNS 慢而超时。
