在 k6 的 `k6/experimental/browser` 模块中，`page.waitfornavigation()` 常因超时、多跳重定向或目标页未就绪而失效；应改用元素存在性断言（如 `waitforselector`）结合显式超时配置，确保稳定捕获最终页面状态。
K6 的浏览器自动化测试（基于 Chromium）中，页面重定向（如登录流程中的多次跳转）容易出现“标题获取不准确”或“浏览器提前关闭”的问题。根本原因并非 waitForNavigation() 本身不可靠，而是它仅监听导航事件触发，不保证目标页面 DOM 已加载完成或关键元素已渲染——尤其在现代 SPA 应用中，路由切换可能不触发完整导航（如使用 History API），或后端重定向链过长导致超时。
✅ 推荐解决方案：用 waitForSelector 替代 waitForNavigation
waitForSelector(selector, options) 会等待指定选择器对应的元素在 DOM 中可见且可交互，天然适配重定向后的页面就绪判断。例如，假设登录成功后页面包含唯一 ID 的欢迎栏：
// ✅ 正确：等待最终页关键元素出现（推荐）
await page.waitForSelector('#welcome-dashboard', { timeout: 30000 });
// ✅ 同时获取标题（此时必为最终页）
console.log('Final page title:', await page.title());⚙️ 必须配合的超时配置
- 全局浏览器超时：已在 chromium.launch() 中设置 timeout: '120s'，合理；
-
上下文超时：需显式为 browser.newContext() 设置，否则继承默认较短超时（通常 30s）：
const context = browser.newContext({ timeout: '120s' }); // 关键！ -
单次等待超时：waitForSelector 或 waitForNavigation 均建议显式传入 timeout，避免依赖全局默认值：
await page.waitForSelector('#user-profile-menu', { timeout: 45000 });
? 不推荐的做法（原代码问题分析）
- sleep(10) 是反模式：无法应对网络波动，既低效又不可靠；
- 连续调用 waitForNavigation() 但未处理重定向链中断（如 302 → 302 → 200），易因中间跳转过快而错过最终导航事件；
- waitUntil: 'networkidle' 在首屏加载后即返回，不适用于后续异步重定向场景。
✅ 优化后的关键流程示例
// 替换原 waitForNavigation + sleep 组合
await Promise.all([
page.waitForSelector('#login-method-selection-password-login-button', { timeout: 30000 }),
continueButton.click(),
]);
// 登录后等待最终页核心元素（非 URL 或 title）
await page.waitForSelector('#dashboard-header', { timeout: 45000 });
console.log('✅ Final title:', await page.title()); // 此时 100% 为最终页? 额外建议
- 使用 page.url() 验证当前地址是否符合预期，作为辅助断言；
- 对关键步骤添加 check() 断言（如 check(page, { 'Title matches': () => page.title().includes('Dashboard') })），提升可观测性；
- 生产环境务必启用 headless: true 并移除 slowMo，仅调试时开启。
通过以页面语义化元素为等待锚点，配合精细化超时控制，即可彻底解决 K6 浏览器测试中重定向状态捕获不准的问题，大幅提升脚本稳定性与可维护性。
