html本身不能直接做e2e测试，因其静态特性无状态、不发请求、不执行逻辑；e2e必须运行在http服务（如localhost）上，通过playwright等工具模拟真实用户交互，并基于语义化定位器断言可见性、可交互性及属性变化。
HTML本身不能直接做E2E测试——E2E测试的对象从来不是单个index.html文件，而是运行在浏览器中的、包含HTML+CSS+JS+网络请求+后端交互的完整应用。你真正要测的，是用户点按钮、填表单、跳转页面后，整个链路是否走通。
为什么不能只测HTML文件？
静态HTML没有状态、不发请求、不执行逻辑，playwright或cypress加载它之后，几乎什么都做不了。常见错误包括：
- 用
npx playwright test直接打开file://路径的HTML，结果page.goto('file:///...')失败或JS不执行 - 测试里写
await page.click('button')，但按钮绑的onclick是内联JS，而Playwright默认不执行javascript:;伪协议或未启用JS的上下文 - 以为“能渲染出文字”就等于通过，但没验证实际行为（比如点击后是否触发了
fetch、是否跳转到正确URL）
真正的E2E必须跑在HTTP服务上：哪怕只是http://localhost:5173这种本地开发服务器。
用Playwright启动本地服务并测试HTML页面
如果你只有纯HTML（比如一个静态文档站、营销页），最轻量的做法是用serve起服务，再让Playwright访问它。不需要React/Vue等框架。
- 安装静态服务器：
npm install -g serve - 在HTML所在目录执行：
serve -s . -p 8080（假设index.html在当前目录） - 写测试时，
baseURL设为'http://localhost:8080'，而不是file:// - 测试中访问首页：
await page.goto('/')，而非page.goto('index.html') - 确保HTML里引用的JS/CSS路径是相对路径或根路径（如
/script.js），避免404导致脚本不执行
这样，playwright就能真实加载、执行、交互——和用户打开Chrome一模一样。
测试中怎么断言HTML内容是否符合预期？
别只用page.textContent()或page.innerHTML()粗暴比对。E2E要验证的是“用户看到什么、能做什么”，不是源码字符串。
- 检查可见文本：
await expect(page.getByText('立即购买')).toBeVisible() - 检查元素存在且可交互：
await expect(page.getByRole('button', { name: '提交' })).toBeEnabled() - 检查属性变化（如禁用态）：
await expect(page.getByLabel('邮箱')).toHaveAttribute('required', '') - 避免用
page.waitForSelector('div#header')这种脆弱写法；优先用语义化定位器，如getByRole、getByLabel、getByText
如果HTML里没写role或aria-label，现在就补上——这不是为测试，是为可访问性，而E2E只是顺便受益。
CI环境里跑HTML E2E容易卡在哪？
本地能过，CI报timeout或net::ERR_CONNECTION_REFUSED，大概率是服务没起来就开测了。
- Playwright配置里别依赖
webServer字段自动启服务（它不支持serve命令的异步就绪检测） - 改用手动等待：在
test.beforeEach里加await execa('npx', ['serve', '-s', '.', '-p', '8080'], { stdio: 'ignore' })，再用await waitForPort(8080)轮询端口就绪 - Docker CI里记得暴露端口：
-p 8080:8080，且serve要加-l 0.0.0.0:8080绑定所有接口 - 截图/录屏功能在CI里默认关闭，如需调试，显式设
screenshot: 'on'和video: 'on'
HTML E2E最常被低估的复杂点，其实是环境一致性——不是语法难，而是本地一个serve命令，到了CI就得考虑进程管理、端口冲突、资源清理。别跳过这一步，否则90%的失败都发生在这儿。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
