Playwright测试CDN组件需显式等待JS初始化完成，优先用role或testid定位，固定CDN版本号，并结合HTMLHint校验渲染后DOM结构。
CDN引入的组件库怎么写Playwright测试
直接用 CDN 加载的组件（比如 Bootstrap Modal、Element UI 的 <el-button>）没有构建产物、不走打包流程，Playwright 测试时最常卡在“元素找不到”或“交互无响应”。核心原因是：CDN 资源加载异步，而 Playwright 默认不等 JS 初始化完成就执行断言。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 所有基于 CDN 的组件操作前，必须显式等待组件就绪。例如 Bootstrap Modal 弹出后，不能只等
.modal元素出现，得等.modal.show类生效或aria-hidden="false"属性变更 - Element UI 场景下，
<el-button>渲染依赖 Vue 实例挂载完成，Playwright 中需先确认document.querySelector('#app').__vue__存在，或用page.waitForFunction(() => window.app?.$children.length > 0) - 避免用纯 class 名定位，优先用语义化属性：
page.getByRole('button', { name: '提交' })比page.locator('.el-button')更稳定 - CDN 版本不一致会导致行为差异（如 Element UI 2.13.2 和 2.15.6 对
disabled的处理不同），测试脚本里应固定 CDN URL 中的版本号，别用@latest
HTMLHint + Playwright 怎么联动检查结构合规性
HTMLHint 能发现标签嵌套错误、缺失 alt、重复 id 等问题，但单独运行是静态扫描；和 Playwright 结合才能验证“渲染后的真实 DOM 是否符合预期”。两者不是替代关系，而是分层校验。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- CI 流程中先跑
htmlhint src/**/*.html检查模板源码，再用 Playwright 启动浏览器，调用page.content()获取渲染后 HTML，喂给 HTMLHint 的 Node API 做二次校验（注意过滤掉框架注入的临时节点，如 Vue 的data-v-xxx） - 对动态生成内容（如 JS 拼接的表格行），HTMLHint 静态扫描必然漏检，必须靠 Playwright 执行 JS 后抓取 DOM 再校验。例如：
await page.evaluate(() => document.querySelector('#user-table').innerHTML) - 把关键规则做成 Playwright 断言：比如强制要求所有图片有
alt，可写成await expect(page.locator('img:not([alt])')).toBeHidden() -
id-unique规则在 SPA 场景容易误报——Vue/React 可能复用同一模板多次渲染，导致多个同名id。此时应改用data-testid代替id作为测试锚点
纯HTML组件库如何避免Playwright误判样式失效
没有 Shadow DOM、没有 CSS-in-JS 的纯 HTML/CSS 组件（如带 .c-button 前缀的按钮），Playwright 容易把“样式未生效”当成“功能异常”，实际只是 CSS 变量未注入或重置样式干扰。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 测试前主动注入设计令牌：用
page.addStyleTag注入基础 CSS 变量，确保var(--c-color-primary)有值，否则padding: var(--c-space-md)会退化为 0 - 禁用全局 reset 是硬性前提。若测试环境加载了 Normalize.css，按钮边框可能被重置为 0，Playwright 看到“按钮没边框”就报错，实际是 reset 干扰而非组件缺陷
- 不要断言 computed style，而要断言最终视觉表现。例如验证按钮颜色，用
await expect(button).toHaveCSS('background-color', 'rgb(0, 102, 204)')不可靠（受父级filter或opacity影响），改用截图比对或检查 class 是否存在更稳 - 移动端断点类（如
col-md-6）在 Playwright 默认桌面视口下不生效，测试响应式必须显式设置 viewport：page.setViewportSize({ width: 768, height: 600 })
服务端渲染模板（Thymeleaf/Go template）怎么测组件交互
Thymeleaf 或 Gin 的 HTML 模板本身不执行 JS，但页面里仍会引用 CDN 组件库。Playwright 测试这类页面时，容易混淆“服务端渲染结果”和“客户端 JS 行为”的责任边界。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 先验证服务端输出是否正确：用
response.text()拿到原始 HTML 字符串，检查是否有th:fragment="header"被正确展开、th:each是否生成了预期数量的<li> - 再验证客户端行为：等
load事件后，检查由 JS 驱动的交互是否可用。例如 Thymeleaf 渲染出<div id="chart-container"></div>，后续由 Chart.js 渲染图表，Playwright 必须等canvas出现而非仅看div - Spring Boot 的 Thymeleaf 模板默认关闭自闭合标签支持（如
<img />会报错），Playwright 截图时若看到<img>没闭合，不是 bug，是模板解析失败导致 DOM 结构损坏，需先修复 Thymeleaf 配置 - 避免在测试中 mock 服务端数据。真实请求后端接口，用 Playwright 的
route拦截并返回 fixture 数据，这样能同时验证模板渲染逻辑和 JS 数据绑定逻辑
