前端 Cookie 登录态怎么防回归：用 Playwright 覆盖跨域请求、CORS 与 SameSite

订单后台有一次看似普通的发布：账号密码提交后跳到了首页，接口也返回200，可第二天调整了网关的跨域规则，用户一刷新就直接回到游客状态。单测覆盖不到浏览器实际有没有把Cookie带出去，靠人工逐个校验又很容易漏掉跨域和HTTPS这类边界场景。这类场景更适合把登录态校验当成一套浏览器自动化链路来稳定维护。

先把登录态拆成一条可观察的链路

浏览器登录不是一个单点结果，而是四段连续动作：登录响应设置凭证，浏览器保存凭证，业务请求按规则发送凭证，服务端据此返回用户信息。任何一段断开，页面都可能出现“刚登录就掉线”的问题。

因此，回归测试的最小目标不是“点击后跳转到首页”，而是：登录后调用 /api/me 拿到当前用户信息；刷新页面后仍能得到同一个用户；Cookie 属性与部署域名完全匹配。

准备一份不会掩盖问题的测试环境

先准备两个地址：页面地址 https://app.example.test，接口地址 https://api.example.test。它们是不同源，但仍属于同一站点的常见子域部署形态。测试账号只需配置一个固定的演示用户，避免用生产账号运行自动化脚本。

前端请求显式声明凭证：

export async function loadCurrentUser() {
  const response = await fetch('https://api.example.test/api/me', {
    credentials: 'include'
  });

  if (!response.ok) throw new Error(`profile ${response.status}`);
  return response.json();
}

服务端的关键响应头也要固定下来。允许来源不能写成通配符，因为带凭证的跨源请求不会接受 *：

Access-Control-Allow-Origin: https://app.example.test
Access-Control-Allow-Credentials: true
Set-Cookie: sid=demo-session; Path=/; Domain=.example.test; HttpOnly; Secure; SameSite=Lax

用 Playwright 写出最小登录回归用例

下面的用例不依赖 Network 面板截图，直接从浏览器上下文读取 Cookie，并在刷新后检查用户昵称。这里不用急着把所有异常场景塞进一个测试用例；一个能明确指出断点的失败提示，比“登录失败”四个字的模糊返回有用得多。

import { test, expect } from '@playwright/test';

test('登录后刷新页面仍保留会话', async ({ page, context }) => {
  await page.goto('https://app.example.test/login');
  await page.getByLabel('邮箱').fill('demo@example.test');
  await page.getByLabel('密码').fill('demo-password');
  await page.getByRole('button', { name: '登录' }).click();

  await expect(page.getByTestId('user-name')).toHaveText('演示用户');

  const cookies = await context.cookies('https://api.example.test');
  const session = cookies.find(item => item.name === 'sid');
  expect(session, '登录响应没有留下 sid').toBeTruthy();
  expect(session?.httpOnly).toBe(true);
  expect(session?.secure).toBe(true);

  await page.reload();
  await expect(page.getByTestId('user-name')).toHaveText('演示用户');
});

如果前端与接口不在同一站点，才需要把 Cookie 设为 SameSite=None; Secure。不要把这个组合当成默认配置：先理清实际的页面域名、接口域名和嵌入方式，再决定对应的策略。

为跨域凭证单独加一道门禁

登录页能打开、Cookie 也存在，仍不代表跨域读取一定成功。网关配置被误改成 Access-Control-Allow-Origin: * 时，浏览器会直接阻止带凭证的响应被脚本使用。给这类边界补一个专门用例，失败时问题就能直接定位到网关或后端跨域配置，不需要前端同学从页面状态反向猜测。

test('用户接口允许页面来源携带凭证', async ({ page }) => {
  await page.goto('https://app.example.test/login');
  await page.getByLabel('邮箱').fill('demo@example.test');
  await page.getByLabel('密码').fill('demo-password');
  await page.getByRole('button', { name: '登录' }).click();

  const response = await page.waitForResponse(item =>
    item.url().includes('/api/me') && item.request().method() === 'GET'
  );

  expect(response.status()).toBe(200);
  expect(await response.json()).toMatchObject({ name: '演示用户' });
});

这段测试顺带验证了页面真实发起的请求。如果它运行失败，按下面顺序排查会更省时间：

• 登录响应有没有 Set-Cookie；没有时先查服务端会话与反向代理配置。
• 上下文里有没有 sid；没有时查 Domain、Path、Secure 与协议配置。
• /api/me 是否返回 401；有 Cookie 仍返回 401 时再查会话存储、过期时间或多实例共享配置。
• 控制台是否出现 CORS 提示；这时重点核对具体来源和凭证许可是否同时返回。

把三种失败结果留在 CI 里

一条登录测试只报红不够实用。更合理的做法是按失败类型保存 Playwright trace、控制台日志和最近一次响应状态：

• 没有 Cookie：通常是响应头、HTTPS 或 Cookie 属性不匹配。
• Cookie 存在但接口 401：优先看会话是否被后端识别、是否过期，或多实例是否共享。
• 接口被浏览器拦截：优先看 CORS 的具体来源与凭证许可，而不是修改页面重试。

CI 中可以把这组浏览器用例放在部署后的冒烟阶段。先跑登录、刷新、退出三个关键路径，再放量给真实用户。测试通过只能证明当前测试域名和账号路径配置正确，灰度环境仍应使用自己的域名与协议再跑一遍校验。

相关问题

只用接口测试能覆盖 Cookie 登录态吗？

不能完全覆盖。接口测试能验证服务端返回，但浏览器是否保存、是否受 SameSite 与跨源规则影响，需要浏览器上下文才能完整确认。

开发环境为什么常常通过，线上却掉登录？

常见差异是线上启用了 HTTPS、反向代理和不同子域，Secure、Domain 与跨源响应头的实际效果就会变得不同。

Cookie 已经存在，为什么 fetch 仍不带它？

跨源请求默认不会携带凭证。检查请求是否使用 credentials: 'include'，以及服务端是否返回了具体来源和凭证许可。

什么时候应改用 Token 放在请求头？

这取决于应用架构与安全模型。若改用请求头令牌，也要明确存储位置、刷新策略和 XSS 风险，不能只因为 Cookie 配置麻烦就仓促切换。

把“登录成功”变成可重复验证的结果

登录接口的 200 只是起点。用 Playwright 连续验证页面状态、Cookie 属性、跨源用户接口和刷新后的结果，才能把一次偶发的掉线问题变成清晰的发布门禁。每次改网关、域名、HTTPS 或会话策略时，先运行一遍这组测试，登录态就不会只靠人工记忆来维护。