playwright 默认在测试用例执行完毕后自动关闭浏览器上下文和页面，这是其设计的资源清理机制；若需保持页面活跃、便于调试或实现长时交互，必须通过显式控制生命周期、禁用自动关闭策略，并改用声明式断言替代硬编码等待。
playwright 默认在测试用例执行完毕后自动关闭浏览器上下文和页面，这是其设计的资源清理机制；若需保持页面活跃、便于调试或实现长时交互，必须通过显式控制生命周期、禁用自动关闭策略，并改用声明式断言替代硬编码等待。
在 Playwright 中，浏览器（browser）、上下文（context）和页面（page）均遵循“作用域即生命周期”的原则：当 test() 函数执行结束，由 @playwright/test 自动管理的 page 和 context 会立即被销毁，进而触发浏览器进程退出——这正是你观察到“自动化运行时窗口一闪而过”，而手动调用 page.pause() 却能停留的原因：pause() 会阻塞执行流，使测试未真正结束。
✅ 正确做法：禁用自动关闭 + 使用声明式断言
1. 阻止测试框架自动关闭页面（关键！）
在 playwright.config.ts（或 .js）中配置 use 选项，禁用 closePage 和 closeContext 的自动行为：
// playwright.config.ts
import { defineConfig } from '@playwright/test';
export default defineConfig({
use: {
// ? 关键：禁止测试结束后自动关闭 page 和 context
closePage: false,
closeContext: false,
// 可选：启用有头模式便于观察
headless: false,
// 可选：减慢执行速度辅助调试
slowMo: 500,
},
});
⚠️ 注意：此配置仅影响
@playwright/test运行器。若使用playwright-core手动启动（如chromium.launch()），则需自行管理browser.close()调用时机。
2. 替换 waitForTimeout() 为可靠断言（推荐实践）
你代码中大量使用的 await page.waitForTimeout(2000) 是反模式：它不校验业务状态，仅盲目等待，既低效又脆弱。应改用 Locator Assertions，例如：
// ✅ 推荐：等待关键元素可见（自动重试，默认 5s 超时）
await expect(page.getByRole('button', { name: 'Got it!' })).toBeVisible();
// ✅ 等待搜索结果列表加载完成（支持动态数量校验）
const searchResults = page.locator('li[data-test="property-card"]');
await expect(searchResults).toHaveCount(10, { timeout: 10_000 });
// ✅ 等待特定 ZIP 码卡片出现（精准语义化断言）
await expect(
page.locator('li', { hasText: '37421' })
).toBeVisible({ timeout: 15_000 });
✅ 优势：
使用Playwright API直接进行浏览器自动化。导航网站、与元素交互、提取数据、截图、生成PDF、录制视频，自动化复杂工作流程。比MCP方法更可靠。
- 自动轮询 + 智能超时，不浪费毫秒；
- 与 Playwright 的自动等待机制深度集成，规避
StaleElementReferenceError； - 语义清晰，可读性与可维护性远超
$$+length+evaluate组合。
3. 安全处理动态弹窗（如 Google 登录框）
你当前通过 frameLocator 关闭 Google 弹窗的方式存在竞态风险（iframe 可能未加载完成）。更健壮写法是：
// 等待 iframe 加载完成后再操作
await expect(
page.frameLocator('iframe[title="Sign in with Google Dialog"]')
).toBeAttached({ timeout: 8_000 });
await page
.frameLocator('iframe[title="Sign in with Google Dialog"]')
.getByLabel('Close')
.click()
.catch(() => console.log('Google dialog not present or already closed'));
4. 若需永久保持浏览器打开（调试/交互场景）
可在测试末尾添加阻塞逻辑，但仅限开发环境：
test('debug zillow flow', async ({ page }) => {
// ... your automation steps ...
// ? 保持页面打开，直到用户手动关闭或按 Enter（Node.js 环境）
console.log('\n✅ Automation completed. Press ENTER to close browser...');
await page.waitForEvent('close').catch(() => {}); // 忽略关闭事件异常
// 或使用：await new Promise(r => process.stdin.once('data', r));
});
? 提示：生产测试中绝不应依赖人工干预。长期运行场景建议改用
persistentContext模式（需配合launchPersistent），但该模式不适用于@playwright/test，需切换至playwright-core手动管理。
? 总结：三大避坑原则
| 错误做法 | 推荐方案 | 原因 |
|---|---|---|
await page.waitForTimeout(2000) |
await expect(locator).toBeVisible() |
硬等待不可靠，断言驱动才是 Playwright 核心范式 |
const els = await page.$$('.List-c11n...'); if (els.length > 0) {...} |
const count = await locator.count(); if (count > 0) {...} |
$$(...) 返回静态 ElementHandle 数组，易失效；locator.count() 是动态查询 |
| 依赖默认 test 生命周期 | 配置 closePage: false + 显式 page.close()
|
默认清理机制无法满足调试/长连接需求 |
遵循以上方案，你的 Zillow 脚本将不再“闪退”，而是稳定停留在目标页面，同时具备生产级的健壮性与可维护性。
