HTML模板本身不参与自动化测试与发布流程，仅作为静态载体提供结构锚点、环境变量注入入口和资源加载声明；真正驱动测试、构建与发布的，是JSON Schema配置、Playwright/Vitest等测试框架及CI/CD工具链的协同。
HTML 模板本身不参与自动化测试流程，也不驱动组件发布——它只是静态载体；真正串联测试、构建、发布的，是配置结构（如 JSON Schema）、测试框架（如 Playwright/Vitest）和 CI/CD 工具链的协同。
为什么直接在 HTML 模板里写测试逻辑行不通
常见错误现象：TypeError: document.querySelector() is null——脚本执行时 DOM 还没加载完；更根本的问题是，纯 HTML 文件没有执行上下文，<script> 里写的断言无法被 CI 系统识别、无法失败退出、也无法生成标准测试报告。
- 使用场景：有人把
expect(...).toBe(...)写在内联<script>里，手动刷新看 console，这不算自动化，CI 跑不了，覆盖率统计不到 - 性能影响：内联脚本随 HTML 一起下载解析，拖慢首屏，且无法按环境开关（比如只在 test 环境启用）
- 兼容性影响：
document在 JSDOM（Vitest 默认）中模拟程度有限，IntersectionObserver、ResizeObserver等需手动 mock，而真实浏览器（Playwright）里它们天然可用
组件发布前必须跑通的测试类型与对应工具选型
不是所有测试都适合塞进 HTML 模板，得按验证层级拆开：
-
单元/集成测试：验证单个组件逻辑（如表单校验、状态切换），用
Vitest+@testing-library/dom，跑在 JSDOM 上，快但需补全缺失 API -
E2E 测试：验证组件在真实页面中的行为（如点击按钮后弹窗出现、API 返回后表格渲染），用
Playwright加载你的index.html或本地服务，能测样式、布局、跨 iframe 交互 -
构建产物检查：发布前校验打包输出是否含预期资源、
data-testid是否残留、关键 script 标签是否正确注入——靠jest或自定义 Node.js 脚本读取dist/目录做断言，不是靠 HTML 自身
HTML 模板在发布流中实际承担的角色
它只做三件事，且必须被“去职责化”：
立即学习“前端免费学习笔记（深入）”；
-
占位与结构锚点：提供
<div id="app"></div>或<my-form data-testid="login-form"></my-form>，供测试脚本精准定位，而非承载逻辑 -
环境变量注入入口：通过
<script>window.__CONFIG__ = {...}</script>注入运行时配置，避免硬编码，但配置本身来自构建时注入（如 Webpack DefinePlugin） -
资源加载声明：用
<link rel="preload">或<script type="module">声明依赖，但加载逻辑、错误降级、超时重试均由 JS 控制，HTML 不参与决策
最容易被忽略的一点：组件能否发布，不取决于 HTML 里有没有 data-testid，而取决于 Playwright 脚本能否在真实浏览器中完成端到端操作闭环，并返回 exit code 0；HTML 只是那个被打开的页面，不是裁判，也不是发动机。
