Playwright 脚本执行完毕后浏览器自动关闭是默认行为，而非异常；根本原因在于测试生命周期结束触发资源清理。本文详解其机制，并提供基于 expect().toBeVisible() 的动态等待方案、防 stale 元素的最佳实践，以及调试与长期驻留的可靠策略。
playwright 脚本执行完毕后浏览器自动关闭是默认行为，而非异常；根本原因在于测试生命周期结束触发资源清理。本文详解其机制，并提供基于 `expect().tobevisible()` 的动态等待方案、防 stale 元素的最佳实践，以及调试与长期驻留的可靠策略。
在 Playwright（尤其是 @playwright/test）中，浏览器窗口“提前关闭”并非 Bug，而是框架设计的预期行为：每个测试用例（test()）运行结束后，Playwright 会自动关闭其关联的 page、context 和 browser 实例，以确保测试隔离性与资源洁净——这正是你手动调用 page.pause() 时能看见页面、而自动化运行却一闪即逝的根本原因。
你的代码中大量使用 await page.waitForTimeout(2000) 是典型误区。硬编码等待既不可靠（网络/渲染波动易导致超时或冗余等待），又无法真正表达业务意图（例如：“等待登录成功提示出现”，而非“等两秒”）。更严重的是，$$ + textContent + length 的组合存在三重风险：
-
$$返回静态 DOM 元素数组，后续.evaluate()无法响应页面动态更新； -
liElement.$('button')可能在元素重绘后失效，引发 Stale Element 异常； -
ulElement.length > 0依赖 JS 层属性，绕过了 Playwright 内置的自动重试与超时机制。
✅ 正确做法：全部替换为声明式 Locator + 断言（Assertions）
// ✅ 推荐：用 toBeVisible 精准等待关键状态，自动重试 + 智能超时
await expect(page.getByRole('button', { name: 'Got it!' })).toBeVisible({ timeout: 8000 });
await page.getByRole('button', { name: 'Got it!' }).click();
await expect(
page.getByPlaceholder('Enter an address, neighborhood, city, or ZIP code')
).toBeVisible({ timeout: 10000 });
await page
.getByPlaceholder('Enter an address, neighborhood, city, or ZIP code')
.fill('Chattanooga');
await expect(page.getByRole('button', { name: 'Submit Search' })).toBeVisible();
await page.getByRole('button', { name: 'Submit Search' }).click();
// ✅ 替换 $$ + length → 使用 locator.count() 获取实时数量
const listItems = page.locator('li').filter({ has: page.locator('text=37421') });
await expect(listItems).toHaveCount(1, { timeout: 15000 }); // 等待含"37421"的项出现
// ✅ 安全点击：直接对 locator 操作，无需手动 $ 查询
await listItems.first().getByRole('button').click();
console.log('Successfully clicked listing with ZIP 37421');
? 关键原则总结：
使用Playwright API直接进行浏览器自动化。导航网站、与元素交互、提取数据、截图、生成PDF、录制视频，自动化复杂工作流程。比MCP方法更可靠。
-
永远避免
waitForTimeout：它不感知页面状态，仅机械计时； -
禁用
$$,$,textContent等低层 API：它们脱离 Playwright 的自动等待、重试和防 stale 保障； -
坚持使用
locator链式调用 +expect(locator).xxx()：这是 Playwright 稳定性的核心基石； -
利用
filter(),first(),last(),nth()等方法替代数组遍历：语义清晰且具备内置重试。
? 若需长期保持浏览器打开（如调试、人工接管、持续监控场景），有两类方案：
-
测试内临时驻留（推荐调试）
在测试末尾添加阻塞逻辑，但不退出进程：test('debug session - keep browser open', async ({ page }) => { await page.goto('https://zillow.com'); // ... your steps ... console.log('✅ Script completed. Browser will stay open for 5 minutes.'); await page.waitForTimeout(5 * 60 * 1000); // 5分钟人工观察期 }); -
全局复用浏览器实例（生产级长连接）
绕过@playwright/test生命周期，改用底层 API 手动管理：const { chromium } = require('playwright'); (async () => { const browser = await chromium.launch({ headless: false }); const context = await browser.newContext(); const page = await context.newPage(); await page.goto('https://zillow.com'); // 执行操作... console.log('Browser launched and ready. Press Ctrl+C to exit.'); // 不调用 browser.close()，进程保持运行 process.stdin.resume(); // 防止 Node.js 自动退出 })();
⚠️ 注意事项：
- 在 CI/CD 环境中严禁长期驻留浏览器，必须严格遵循
browser.close()清理； - 启用
headless: false时，建议搭配slowMo: 500（减慢执行）便于肉眼验证； - 对抗反爬网站（如 Zillow）时，务必注入反检测参数（如
--disable-blink-features=AutomationControlled）并覆盖navigator.webdriver，否则可能因风控被强制跳转或封禁。
掌握这些模式后，你的 Playwright 脚本将兼具稳定性、可读性与可维护性——不再“猜时间”，而是“等状态”；不再“怕关闭”，而是“控生命周期”。
