HTMLHint是最实用的HTML静态检查入口，因其轻量、可配置、开箱即用，将W3C/ARIA/SEO规范转化为可执行规则，支持CLI、CI及VS Code联动，在git commit或保存时即报错，真正实现“错误不入库”。
HTML 本身没有类型系统，但“基于静态类型检查思想”在 HTML 工程化实践中，本质是用外部工具对结构、属性、语义做编译前约束——它不检查 string 或 number，而是检查 class 是否拼错、role 是否合法、aria-* 是否匹配元素上下文、src路径是否存在等。这类检查能拦截大量低级但高频的 HTML 错误，比如挂载失败的图片、不可访问的表单控件、SEO 友好性破坏。
为什么 HTMLHint 是当前最实用的静态检查入口
HTMLHint 是轻量、可配置、社区维护活跃的 CLI 工具，不依赖构建流程，开箱即用。它把 HTML 规范（W3C、ARIA、SEO）和工程实践（如 class 命名约定、内联样式禁用）转化为可执行规则。相比浏览器 DevTools 的运行时检查，HTMLHint 在 git commit 或 CI 阶段就能报错，真正实现“错误不入库”。
- 默认规则已覆盖常见陷阱：比如
attr-no-duplication检查重复属性，attr-req-value拦截空href或src - 支持自定义规则：可通过
.htmlhintrc关闭宽松项（如attr-lowercase），启用严格项（如id-class-ad-disabled禁止 ad 相关 class 名） - 与 VS Code 插件联动后，保存即提示，无需手动运行命令
如何让 HTMLHint 检查真正落地，而不是形同虚设
很多团队装了 HTMLHint 却没效果，核心原因是规则没对齐业务实际。例如电商页大量使用 data- 属性驱动 JS 行为，若启用 attr-unknown（禁止未知属性），就会误报；又如 SSR 场景下 required 属性可能被服务端逻辑动态控制，硬性要求会阻塞发布。
- 先跑一次全量扫描：
npx htmlhint src/**/*.html，导出问题列表，按频率排序，只保留 top 5 高发问题对应的规则 - 把
attr-bans设为白名单模式，只禁用明确有害的属性（如onclick），而非全量禁止data- - 对模板引擎生成的 HTML（如 Nunjucks、Handlebars），关闭
attr-no-duplication—— 模板继承可能导致属性重复，但渲染后是合法的 - CI 中加
--max-warnings 0参数，让任何警告都导致构建失败，避免“警告太多就忽略”
HTML 静态检查与 TypeScript 类型检查的关键差异
不能把 HTMLHint 当成“TypeScript for HTML”。TypeScript 的 interface 定义的是值的形状，而 HTMLHint 的规则定义的是文档的合规形状——前者能推导 user.name 必为 string，后者只能告诉你 <input type="email"> 缺少 required 属性是否违反团队规范。
立即学习“前端免费学习笔记（深入）”；
- TypeScript 类型错误 = 编译失败；HTMLHint 错误 = 文档质量风险，不一定阻断运行
- TypeScript 有泛型、联合类型等表达力；HTMLHint 规则粒度粗，无法表达“当
role="tablist"时，子元素必须含role="tab"”这类嵌套约束 - 真正接近“类型契约”的方案是结合
schema.orgJSON-LD 校验或自定义 Web Component 的observedAttributes类型声明，但这已超出 HTMLHint 能力范围
HTML 静态检查的价值不在“多严”，而在“准不准”——规则要贴着真实渲染链路设，否则要么漏报关键可访问性缺陷，要么被模板语法、SSR 注入、构建插件产出的临时属性反复误伤。工具只是放大镜，照哪里、怎么调焦，得由人决定。
