推荐使用html-validate而非HTMLHint，因其支持ARIA规则、WCAG合规性校验及现代HTML5语义，可配合pre-commit钩子与CI卡点（--fail-on-warn）实现真正有效的HTML质量管控。
HTML 代码质量不是靠肉眼检查或“差不多就行”能守住的，必须嵌入 CI/CD 流水线并绑定提交和构建环节。否则，无效标签、缺失 alt、不规范的 aria- 属性、错误嵌套等会持续流入生产环境，最终拖累可访问性、SEO 和维护成本。
HTML 静态检查该用哪个工具？
别用 htmlhint 做主力 —— 它规则老旧、插件生态停滞，对现代语义 HTML5（如 <dialog></dialog>、<slot></slot>）支持弱，且无法与 Linter 统一配置。推荐组合：eslint-plugin-html + eslint 主体配置，或更彻底的 prettier + html-validate。
-
html-validate是目前唯一能深度校验 ARIA 规则、WCAG 合规性、自定义元素生命周期、以及模板语法（如 Vue/React 中内联 HTML 片段）的开源工具 - 它支持 JSON Schema 配置，可直接复用团队已有的 WCAG 2.1/2.2 检查清单，比如强制
img必须有alt或role="presentation" - 注意：它默认不处理 JSX 或 Vue SFC 中的
<template></template>块，需配合html-validate-loader（Webpack）或eslint-plugin-vue的vue/multi-word-component-names等规则协同工作
如何让 HTML 检查进 Git 提交钩子？
仅靠 CI 阶段报错太晚 —— 开发者已切分支、写完逻辑、甚至提了 PR，再让其返工修复 form 缺少 label，体验极差。真正有效的做法是把 html-validate 接入 pre-commit 钩子，并限定只检查变更文件中的 HTML 片段。
- 用
husky+lint-staged组合，配置lint-staged只对*.{html,htm,vue,jsx,tsx}运行npx html-validate --no-warnings - 关键点：加
--no-warnings参数，避免非阻断性提示干扰提交；同时在 CI 中保留警告级规则输出，用于趋势监控 - 容易踩坑：若项目含大量旧 HTML 文件，首次启用会批量失败。建议先用
html-validate --init生成基础配置，再逐个目录排除（"ignore": ["legacy/**/*.html"]），而非全局关闭
CI 流水线里 HTML 质量怎么才算“卡点成功”？
很多团队把 html-validate 放进 CI 后就以为万事大吉，结果发现它总在“Warning”级别飘红，或只跑一次就过，根本起不到拦截作用。真正的卡点需要两层控制：
立即学习“前端免费学习笔记（深入）”；
- 第一层：构建阶段必须失败 —— 在 Vercel / GitHub Actions / GitLab CI 的
build步骤中，明确设置html-validate src/**/*.html --fail-on-warn。没有这个参数，90% 的问题只是日志刷屏 - 第二层：差异感知 —— 用
html-validate-diff（或自研脚本）对比 PR 分支与main的 HTML 输出产物（如构建后的index.html），只报告本次 PR 引入的新问题。避免因历史债导致每次 PR 都挂 - 性能注意：全量扫描整个
dist/目录很慢。建议只校验入口 HTML 文件（dist/index.html）及动态生成的关键模板（如dist/404.html），其余由组件单元测试覆盖
HTML 不是“写完扔一边”的静态资源，它是运行时结构、无障碍桥梁、SEO 入口，也是前端最易被忽视的质量洼地。工具链整合不难，难的是把每条 alt、每个 role、每处 tabindex 都当成接口契约来对待 —— 它们不是装饰，是交付物的一部分。
