动态页面html质量需在真实浏览器中审计渲染后dom，用puppeteer配合业务埋点等待js执行完成，递归检查iframe及微前端，按critical/serious分级设置ci阈值，并适配不同运行时状态。
动态页面的 HTML 质量不能只靠静态扫描——htmlhint 或 html-validate 会漏掉 JS 渲染后缺失 alt、aria- 属性丢失、id 重复生成等关键问题。必须在真实浏览器中运行并抓取最终 DOM 才能暴露真实缺陷。
用 Puppeteer 启动真实环境，等 JS 渲染完成再审计
很多人直接用 page.content() 拿源码去校验，但那只是 SSR 输出或骨架 HTML，和用户看到的完全不是一回事。真正要测的是“渲染后 DOM”。
- 别只等
networkidle0：它只保证网络请求结束，不保证 JS 执行完。必须配合业务埋点，比如在 JS 最后一行写window.__HTML_AUDIT_READY__ = true，然后await page.waitForFunction('window.__HTML_AUDIT_READY__') - 用
page.evaluate(() => document.documentElement.outerHTML)获取渲染后结构，再交给cheerio或axe-core分析 - 对单页应用（SPA），要手动触发路由跳转：
await page.goto('/product/123', { waitUntil: 'networkidle0' })，再等__HTML_AUDIT_READY__
动态生成的属性必须单独校验，不能依赖模板规则
静态规则集（如 attr-req-alt）对服务端渲染有效，但对 JS 动态插入的 <img> 无效——因为标签根本不在初始 HTML 里。
- 在 Puppeteer 中执行 JS 校验逻辑：
await page.evaluate(() => { return Array.from(document.querySelectorAll('img')).every(img => img.hasAttribute('alt')) }) - 检查重复
id：动态组件多次挂载时极易产生冲突，用document.querySelectorAll('[id]').forEach(el => { /* 统计 id 出现次数 */ }) - 验证
aria-属性是否被 JS 清除：比如某个下拉菜单展开后，aria-expanded="true"是否真的写进了 DOM，而不是仅存在 React/Vue 的 state 里
iframe 和微前端场景下必须递归审计子上下文
跨专业团队常把运营模块、广告位、第三方 SDK 塞进 iframe 或微前端容器里，这些区域的 HTML 完全独立于主站校验流程，是质量盲区。
- 获取所有 iframe：
const frames = await page.frames()，过滤掉空 frame 和 sandbox 限制过严的 - 对每个 frame 执行相同审计逻辑：
await frame.evaluate(() => document.body.innerHTML)，或调用frame.$eval('img', el => el.alt) - 特别注意容器劫持行为：比如钉钉/飞书容器会把
@#@#@#@#@#@#@#@#@#@0替换成@#@#@#@#@#@#@#@#@#@1，原生语义和可访问性全丢，需额外比对href是否被保留或降级为data-href
CI 中失败阈值必须按动态特性分级设置
静态 HTML 报错可以“零容忍”，但动态页面的某些警告（如“JS 未加载完成时 aria-hidden=true”）可能是合理中间态，硬性阻断会拖慢交付节奏。
- critical 级别（如缺失
lang、main重复、img无alt）设为失败门槛：新增 ≥1 条即阻断构建 - serious 级别（如
aria-label冗余、role误用）只告警，但自动记录历史趋势，连续两版增长超 20% 触发人工 review - 避免把
axe-core的inapplicable结果计入统计——它表示规则不适用当前 DOM，不是问题
最易被忽略的点是：动态页面的“质量基线”必须随 JS 运行时状态变化而更新。同一 URL 在不同登录态、灰度开关、AB 实验分组下，合法 DOM 结构可能完全不同——自动化跑测必须能识别并适配这些上下文，否则所谓“通过”只是假阳性。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
