高频交互页质量等级须按真实用户操作路径分层打分，设绿（无阻塞）、黄（可降级）、红（中断或错乱）三级；INP＞500ms、CLS＞0.25、未防抖DOM操作等必须标红；HTMLHint需按页面类型拆分配置，W3C验证器仅校验静态HTML，须结合服务端HTML、客户端DOM快照、运行时错误日志三重校验。
怎么给高频交互页定质量等级
不能只看W3C验证是否通过，得按真实用户操作路径来分层打分。比如一个商品筛选页，点击“价格区间”后触发Ajax加载、同时更新URL和历史记录、还要保持滚动位置——这些交互链路上的每个节点都要单独设权重。
建议用三级分档：绿（无阻塞问题）、黄（存在可降级但不影响主流程的问题）、红（直接导致交互中断或数据错乱）。特别注意INP超过500ms、CLS突增＞0.25、或data-transfer未做防抖的DOM操作，这类必须标红。
- 主操作按钮的
click事件绑定必须在DOMContentLoaded后完成，否则首屏点击失灵 - 动态插入的
form元素要补全name和id，否则FormData收集失败 - 使用
IntersectionObserver做懒加载时，需检查rootMargin是否适配移动端触控区域
为什么HTMLHint规则要按页面类型拆分
通用规则会误伤高频交互页。比如attr-no-duplication对静态页很必要，但在用Vue或React渲染的筛选组件里，v-bind或spread operator可能生成重复class，硬卡这条规则反而阻碍开发。
实际做法是建两套配置：.htmlhint.interactive.json禁用易误报项，但强制开启attr-req-alt（图片必须带alt）、attr-req-id（所有input必须有id）、head-script-disabled（禁止head里写script）；而.htmlhint.static.json保留全部校验。
立即学习“前端免费学习笔记（深入）”；
CI阶段根据pathname匹配路由前缀自动选用对应规则，比如/search/、/cart/走interactive配置。
W3C验证器为什么不能直接用于生产环境扫描
它只校验静态HTML文本，对document.write、innerHTML拼接、或Shadow DOM里的内容完全不可见。曾有个订单确认页，W3C验证全绿，但实际运行中submit按钮被JS动态移除了type="submit"，导致表单无法提交。
真正有效的检查得结合三类输出：
- 服务端吐出的原始HTML（用
cheerio跑语义化和SEO检查） - 客户端渲染后的DOM快照（用
puppeteer执行关键操作后截图+提取aria-*属性） - 运行时错误日志（捕获
DOMException、TypeError: Cannot read property 'xxx' of null等）
三者交叉比对，才能发现“静态合规但运行崩坏”的问题。
历史趋势对比最容易忽略的细节
单纯画个“质量分随时间上升”的折线图没用。高频交互页的质量波动往往和第三方SDK升级强相关——比如某次接入新版埋点SDK，INP平均涨了180ms，但报告里只显示“可访问性提升”，掩盖了性能退化。
必须把每次扫描结果关联到git commit hash和npm ls快照，当某项指标突变时，自动拉出前后差异包列表。尤其盯紧mutationobserver监听范围扩大、resize事件未节流、或custom element定义延迟这几类隐蔽退化点。
