让浏览器 CI 测试 Vite 生产构建，消除开发服务器抖动

一套单页应用的浏览器门禁在打开某个路由时失败。此前生产构建已经完成，体积预算和单元测试均为绿色，另外八条端到端用例也成功。失败页面报告无法从 Vite 开发服务器取得一个路由源码模块。

重新运行任务可能得到绿色结果，却会保留薄弱的验证边界。准备交付的是生成后的静态构建，浏览器门禁依赖的仍是开发期源码转换与按需模块交付。

最终改动让 Playwright 在每次执行时先构建应用，再启动全新的 Vite 生产预览。原有的网络失败注入也从源码文件 URL 改到构建后带哈希的 JavaScript 资产。修改后，九条浏览器用例、本地完整门禁和最终云端检查全部通过。

失败请求暴露了测试服务器边界

失败请求指向一个页面源码模块。这个细节能够区分两种运行模式：Vite 开发服务器会在浏览器请求源码模块时进行转换和交付，路由级动态导入会在导航发生后增加一次开发服务器请求。

应用当时已经成功生成生产构建。Vite 官方文档说明，vite build 会输出适合静态托管的构建包，vite preview 会在本地提供 dist 中的生成文件，便于检查构建结果（Vite 生产构建，Vite 静态部署）。本次失败请求没有经过这条构建资产路径。

现有证据无法进一步证明单次失败来自启动时序、瞬时响应异常，还是其他仅在开发模式存在的条件。可以确认并直接修正的问题是：发布门禁依赖了一种生产环境不会使用的服务器模式。

增加重试无法修正验证对象

当业务行为本身包含明确的异步状态时，重试或等待条件有合理用途。当前问题首先需要校正被验证的产物。

若直接增加重试，会留下三类风险：

• 开发服务器恢复后可能掩盖同一类模块交付失败；
• 绿色结果仍未覆盖生成文件名、生产转换和 dist 内容；
• 浏览器用例可能通过，同时生产构建仍带有基础路径、拆包或资产引用错误。

因此先移动测试目标，再单独判断真实网络或业务流程是否需要重试策略。

让 Playwright 启动干净的生产预览

预览步骤先构建应用，再启动服务器：

vite build
vite preview

包脚本用 && 连接两条命令，构建失败时不会启动预览。主机、测试端点和严格端口等设置继续由测试环境管理，没有被写成文章中的固定常量。

Playwright 的 webServer 配置可以启动命令，并等待指定 URL 开始接受请求；它也能控制是否复用已经存在的服务器（Playwright Web Server）。浏览器配置改为运行生产预览脚本，并禁止复用旧进程：

const testURL = getTestURL()

const webServer = {
  command: 'npm run preview:e2e',
  url: testURL,
  reuseExistingServer: false,
  timeout: 60_000,
}

export default defineConfig({
  webServer,
  use: {
    baseURL: testURL,
  },
})

禁止复用后，若配置的测试端点已被其他进程占用，套件会直接失败。浏览器也不会悄悄连接到本地会话或上一次测试遗留的开发服务器。

如果完整 verify 命令已经在 E2E 前运行过一次 vite build，这个最小模式会重复构建。额外构建增加了时间成本，同时让预览命令保持自包含，并保证服务器读取当前产物。更成熟的流水线可以只构建一次，再把同一份不可变 dist 交给独立服务器步骤；此时必须用产物身份把构建阶段和浏览器阶段精确绑定。

故障注入也要跟随构建资产

其中一条浏览器用例用于验证可选语言包下载失败时，默认语言仍然可用。开发服务器模式下，用例拦截的是 TypeScript 源码模块路径；生产构建中不存在该路径。

Vite 会在生产构建时重写资产引用，并通常在资产目录生成带哈希的文件名（Vite 静态资产处理）。拦截规则因此改为匹配生成后的语言包 chunk：

const localeAsset = new RegExp(
  '/assets/en-US-' +
  '[^/?]+[.]js' +
  '(?:[?].*)?$',
)

async function failLocale(route) {
  await route.abort()
}

await page.route(
  localeAsset,
  failLocale,
)

这条表达式接受内容哈希和可选查询参数，同时把语义目标限制在特定语言包。若使用宽泛的 **/*.js，应用入口或无关 chunk 也会被阻断，测试将无法证明原定降级行为。

构建配置改变 chunk 命名规则时，用例应从构建清单定位目标，或把文件名规则维护为显式契约。只有经过审查且保持精确的模式，才适合作为长期断言。

验证同时覆盖产物和交付链路

完成后的门禁覆盖多个边界：

• lint 与 26 条前端单元测试通过；
• 生产构建成功，构建包体积预算仍在既定上限内；
• 九条 Playwright 用例全部针对全新的生产预览通过；
• 更大范围的仓库测试和仓库契约检查通过；
• 最终云端检查在经过审查的精确提交上完成。

验证顺序提供了有用的因果边界。前一轮云端执行已经证明编译和大多数行为正常，随后才在浏览器阶段失败。调整后的执行进一步证明，同一类用户路径可以在生成后的资产依赖图上工作。

适用边界

Vite 明确把 preview 定义为本地检查生产构建的方式，并说明它不能作为生产服务器。生产预览无法复现 CDN、反向代理、TLS 终止、缓存响应头、压缩策略、Service Worker 和真实生产后端。

依赖开发服务器 API 代理的应用切换到 preview 后，需要准备独立测试后端、fixture 或请求 mock。服务端渲染和运行时资产生成也要使用符合真实交付模型的测试服务器，静态预览无法单独完成验证。

可复用结论是让浏览器 CI 对准发布步骤准备交付的产物：构建一次，或让重复构建绑定同一源码；为该产物启动干净服务器；让故障注入跟随生成资源；同时保留部署后冒烟，覆盖本地预览无法代表的生产行为。