Playwright/test用fixtures时基页加载后如何设置storageState认证

你的核心矛盾是默认storageState的注入时机在浏览器上下文初始化阶段、页面首次导航前，无法满足「先导航到基页等待特定服务写入完成、再注入认证态」的需求，以下是两种可直接落地的方案，完全兼容Playwright Test的page实例隔离机制。

方案1：自定义fixture延迟注入认证态（推荐，适配现有架构） #

放弃在test.use或全局配置中提前绑定storageState，把认证态注入逻辑挪到自定义page fixture中，按你需要的时机手动注入，不破坏用例间的隔离性。

实现代码 #

首先扩展测试fixture：

// fixtures/auth-fixture.ts
import { test as base, expect } from '@playwright/test';
import * as fs from 'fs';

// 定义自定义fixture类型
type AuthFixtures = {
  authedPage: import('@playwright/test').Page;
};

export const test = base.extend<AuthFixtures>({
  // 初始化浏览器上下文时不要提前加载storageState
  context: async ({ browser }, use) => {
    const context = await browser.newContext();
    await use(context);
    await context.close();
  },

  authedPage: async ({ page, baseURL }, use) => {
    // 1. 先导航到基页，等待触发自动登出的特定服务完成写入
    await page.goto(baseURL!, { waitUntil: 'commit' });
    // 替换为你实际的等待逻辑：等待对应接口返回、或特定DOM/存储标记出现，不要硬等固定时长
    await page.waitForResponse(
      resp => resp.url().includes('/api/trigger-logout-service') && resp.finished()
    );

    // 2. 读取预生成的storageState，手动注入到当前上下文
    const storageState = JSON.parse(fs.readFileSync('./storageState.json', 'utf-8'));
    // 注入cookie
    await page.context().addCookies(storageState.cookies);
    // 注入对应域名下的localStorage/sessionStorage
    await page.evaluate((stateOrigins) => {
      stateOrigins.forEach(originItem => {
        if (originItem.origin !== window.location.origin) return;
        // 写入localStorage
        Object.entries(originItem.localStorage).forEach(([key, val]) => {
          window.localStorage.setItem(key, val as string);
        });
        // 有sessionStorage认证数据的话同步写入
        if (originItem.sessionStorage) {
          Object.entries(originItem.sessionStorage).forEach(([key, val]) => {
            window.sessionStorage.setItem(key, val as string);
          });
        }
      });
    }, storageState.origins);

    // 3. 刷新页面让认证态生效，校验登录状态
    await page.reload({ waitUntil: 'domcontentloaded' });
    // 替换为你项目里的登录态校验逻辑，比如等待用户头像、欢迎语出现
    await expect(page.getByTestId('user-profile-avatar')).toBeVisible({ timeout: 10000 });

    // 把处理好的已登录page实例传给用例
    await use(page);
  }
});

export { expect };

测试用例中直接引入自定义fixture即可，每个用例的page实例依然完全隔离：

// test-cases/sample.spec.ts
import { test, expect } from '../fixtures/auth-fixture';

test('登录后可正常访问业务页面', async ({ authedPage }) => {
  // 此时authedPage已经完成认证注入，不会被自动登出
  await expect(authedPage.getByText('业务工作台')).toBeVisible();
});

方案2：路由拦截阻断自动登出逻辑（轻量方案） #

如果能明确定位到触发自动登出的具体接口或前端方法，可以直接在页面初始化阶段加拦截，不需要调整storageState注入时机，改动量更小。

实现示例 #

在现有page fixture中加入拦截逻辑：

page: async ({ page }, use) => {
  // 方式1：拦截触发登出的接口，返回正常响应绕过登出逻辑
  await page.route('**/api/auto-logout-trigger', route => {
    return route.fulfill({
      status: 200,
      contentType: 'application/json',
      body: JSON.stringify({ code: 0, msg: 'success', data: {} }) // 对齐实际接口返回格式
    });
  });

  // 方式2：如果是前端JS主动触发登出，直接在初始化阶段覆写登出方法
  await page.addInitScript(() => {
    (window as any).triggerLogout = () => {};
  });

  await use(page);
}

这个方案适合触发登出的逻辑边界清晰、不会影响核心业务流程的场景。

避坑提示 #

• 不要在测试运行过程中覆盖全局的storageState.json文件，并行执行用例时会出现状态污染
• 注入存储数据时必须校验origin，避免把其他域名的存储内容写入当前上下文
• 等待特定服务加载的逻辑不要用固定等待时长（比如page.waitForTimeout(3000)），要绑定实际的网络请求、DOM标记或存储变化，避免用例偶发失败

内容的提问来源于stack exchange，提问作者Dneprokos