1. Playwright 端对端测试为什么要接统一 Key 通道Playwright 是微软开源的端对端测试框架能驱动 Chromium、Firefox、WebKit 三种浏览器模拟真实用户点击、输入、跳转并对页面标题、元素文本、截图做断言。它适合谁适合所有需要验证「页面多模块联动是否正常」的前端团队尤其是组件库、后台系统、营销页这类交互链路长的项目。单元测试用 Jest 覆盖函数和组件端对端测试用 Playwright 覆盖真实浏览器里的完整流程两者互补。但真正落地时麻烦往往不在测试脚本本身而在「测试里要调模型能力」这件事上。比如你想在端对端流程里加一步让页面上的 AI 助手回答一个问题然后断言回答内容渲染成功或者用模型生成测试数据、校验文案。这时候测试代码里就得有 API Key、Base URL、模型名。如果每个开发者本地各配一套CI 上再配一套Key 散落在.env、playwright.config.js、GitHub Secrets 里排查问题时根本不知道当前跑的是哪条链路。我试过把模型调用统一收敛到一个 Key/API 通道Playwright 侧只读环境变量配置写进settings.json骨架测试脚本不碰明文密钥。这样本地和 CI 用同一套结构换 Key 只改一处。下面按「前置准备 → 配置骨架 → 跑一次验证 → 报错排查」的顺序走一遍你可以直接复制。2. TaoToken 前置Key、通道与项目结构TaoToken 在这里扮演的是统一模型调用入口你拿到一个 Key配好 Base URLPlaywright 测试里通过环境变量读取就能在端对端流程中调用模型对话能力。它不替代 Playwright也不替代你的编辑器只是把「测试代码要调模型」这条链路的凭证和地址统一起来。先做三件事。第一注册并登录控制台在 API Keys 页面创建一个 Key复制保存它只显示一次。第二确认你要用的模型名比如对话类模型记下来。第三确认 Node 版本与 Playwright 版本匹配Node 18 LTS 配 Playwright 1.3x 系列是稳的版本错配会在启动浏览器时报奇怪的错。项目结构建议这样组织让配置和测试分离my-e2e-project/ ├── tests/ │ └── ai-assistant.spec.js ├── .env ├── settings.json ├── playwright.config.js └── package.json.env放本地密钥不进 Gitsettings.json放非敏感的配置骨架比如模型名、超时、重试次数playwright.config.js读环境变量并注入到测试的use里。这样 CI 上只需要在 Secrets 里配同名环境变量结构完全一致。注意Key 只放环境变量或 CI Secrets不要写进settings.json提交到仓库。settings.json里只放可以公开的骨架字段。3. 可复制配置settings.json 骨架与环境变量写法先写settings.json。它的作用是给测试运行器提供一份「默认参数」包括模型通道地址、模型名、请求超时、重试策略。地址用 TaoToken 的 API 入口不带多余参数{ model: { baseUrl: https://taotoken.net/api, modelName: gpt-4o-mini, timeoutMs: 30000, maxRetries: 2 }, e2e: { baseURL: http://localhost:3000, trace: on-first-retry, screenshot: only-on-failure } }baseUrl指向 API 入口modelName换成你实际要用的模型timeoutMs给模型调用留足时间端对端测试里网络慢是常态。e2e段是 Playwright 自己的配置baseURL指向你本地或测试环境的页面地址。接着写.env本地开发用TAOTOKEN_API_KEYsk-你的Key TAOTOKEN_BASE_URLhttps://taotoken.net/api TAOTOKEN_MODELgpt-4o-mini E2E_BASE_URLhttp://localhost:3000然后在playwright.config.js里读取并注入到测试上下文中。这样测试脚本里通过process.env拿到的就是统一后的值const { defineConfig, devices } require(playwright/test); const settings require(./settings.json); module.exports defineConfig({ testDir: ./tests, fullyParallel: true, retries: process.env.CI ? 2 : 0, reporter: html, use: { baseURL: process.env.E2E_BASE_URL || settings.e2e.baseURL, trace: settings.e2e.trace, screenshot: settings.e2e.screenshot, }, projects: [ { name: chromium, use: { ...devices[Desktop Chrome] } }, ], });如果你在测试里要直接调模型建议封装一个小的请求函数把 Key 和 Base URL 从环境变量读进来避免散落// tests/utils/modelClient.js const settings require(../../settings.json); async function askModel(prompt) { const apiKey process.env.TAOTOKEN_API_KEY; const baseUrl process.env.TAOTOKEN_BASE_URL || settings.model.baseUrl; const model process.env.TAOTOKEN_MODEL || settings.model.modelName; if (!apiKey) { throw new Error(TAOTOKEN_API_KEY 未设置请检查 .env 或 CI Secrets); } const res await fetch(${baseUrl}/v1/chat/completions, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${apiKey}, }, body: JSON.stringify({ model, messages: [{ role: user, content: prompt }], }), }); if (!res.ok) { const text await res.text(); throw new Error(模型调用失败 ${res.status}: ${text}); } const data await res.json(); return data.choices[0].message.content; } module.exports { askModel };这段封装的好处是Key 只在环境变量里测试脚本不出现明文Base URL 和模型名有默认值也有覆盖出错时能拿到状态码和响应体方便定位。4. 验证请求跑一次端对端测试确认链路配置写好后写一个最小的端对端用例既验证页面能打开也验证模型通道能通。新建tests/ai-assistant.spec.jsconst { test, expect } require(playwright/test); const { askModel } require(./utils/modelClient); test(页面标题正确且模型通道可用, async ({ page }) { await page.goto(/); await expect(page).toHaveTitle(/我的应用/); const answer await askModel(用一句话说明端对端测试的价值); console.log(模型返回:, answer); expect(answer.length).toBeGreaterThan(0); });先启动你的本地页面服务比如npm run dev确认http://localhost:3000能打开。然后跑测试npx playwright test tests/ai-assistant.spec.js --projectchromium预期输出类似Running 1 test using 1 worker 模型返回: 端对端测试能验证真实浏览器中多模块联动的完整流程。 1 passed (3.2s)看到1 passed且控制台打印出模型返回内容说明两件事都成了Playwright 能驱动浏览器打开页面模型通道也能通过环境变量里的 Key 正常调用。如果只想验证模型通道可以单独跑一个 Node 脚本node -e require(./tests/utils/modelClient).askModel(你好).then(console.log).catch(console.error)这一步能快速区分是「模型通道问题」还是「Playwright 配置问题」。如果这个脚本能打印回答但 Playwright 测试失败问题就在浏览器或页面侧如果这个脚本也失败问题在 Key、Base URL 或网络。5. 本篇常见报错排查报错一TAOTOKEN_API_KEY 未设置。说明环境变量没被读到。检查.env是否在项目根目录Node 是否加载了它。Playwright 默认不会自动读.env你需要在playwright.config.js顶部加require(dotenv).config()并安装dotenv。CI 上则确认 Secrets 名称与代码里读的变量名完全一致大小写敏感。报错二模型调用失败 401。Key 无效或过期。去控制台重新生成一个 Key确认复制时没有多余空格。注意Authorization头是Bearer加 Key中间一个空格别漏。报错三模型调用失败 404。多半是 Base URL 或路径拼错。settings.json里baseUrl是https://taotoken.net/api请求时拼/v1/chat/completions。如果你把baseUrl写成了带/v1的地址就会变成/v1/v1/...。统一在封装函数里拼路径别在多个地方各拼一次。报错四browserType.launch: Executable doesnt exist。浏览器驱动没装。跑npx playwright install chromium国内下载慢可以设PLAYWRIGHT_DOWNLOAD_HOST指向镜像源。注意 Node 版本与 Playwright 版本匹配Node 18 配 Playwright 1.3x 系列版本错配会报启动失败。报错五测试超时但模型脚本正常。页面没起来或baseURL指向的地址不对。确认npm run dev在跑端口和settings.json里e2e.baseURL一致。Playwright 的use.baseURL只影响page.goto(/)这类相对路径绝对路径不受影响。报错六CI 上通过、本地失败或反过来。检查两边环境变量是否一致。本地.env和 CI Secrets 的 Key、Base URL、模型名要完全对齐。CI 上如果用了缓存确认缓存没把旧的settings.json带进去。排查顺序建议固定先跑独立 Node 脚本验证模型通道再跑 Playwright 验证浏览器最后看两者结合。这样每次都能把问题范围缩小一半。6. 接入文档与后续操作入口配置骨架和排查步骤走完链路基本就通了。后续如果你要换模型、加测试用例、或者把模型调用接到更长的编码任务里可以按场景选入口需要创建或轮换 Key、查看接入文档进 API Keys 管理接入细节看 接入文档。想先在网页里验证模型回答效果再写进测试断言用 模型对话。长期做编码、Agent 类任务需要更稳定的额度与通道看 Coding Plan。用 Claude Code 或 Anthropic 风格接口做端对端辅助参考 ClaudeCodeAnthropic 接入。把settings.json骨架提交进仓库.env加进.gitignoreCI Secrets 配同名变量这套结构就能在本地和流水线之间无缝切换。下次换 Key只改 Secrets测试脚本一行不动。