应选用html-validate而非sonarqube或eslint，因其专为html语义与标准合规设计，支持可配置规则、ci集成及无障碍检查，能识别aria属性缺失等真实问题，且需配合宽松配置、独立lint阶段和开发流程闭环（编辑器+git钩子+ci）落地。
CI流程中HTML代码质量扫描该用什么工具
HTML本身没有编译环节，静态扫描依赖解析器而非编译器，所以不能直接套用ESLint或SonarQube的Java/JS插件逻辑。真正能落地的方案只有两类：html-validate（专注HTML语义与标准合规）和tidy（侧重格式修复与基础语法校验）。前者支持规则配置、CI集成、自定义错误级别；后者轻量但仅输出警告/错误，不提供可配置规则集。
别被“HTML Linter”这类模糊关键词误导——很多npm包只是包装tidy或调用浏览器DOM API做简单检查，无法识别语义错误（如<div>嵌套<code><h1></h1>却无<section></section>包裹）、ARIA属性缺失、或aria-hidden与tabindex冲突等真实问题。
html-validate在CI脚本里怎么跑才不失败
默认配置下html-validate会严格校验W3C标准，而实际项目常存在合法但非标准写法（比如Vue单文件组件里的<template></template>根节点、React JSX生成的data-* 属性），直接执行npx html-validate src/**/*.html大概率报错退出，导致CI流水线中断。
- 必须用
--config指定宽松配置，例如html-validate --config .htmlvalidate.json src/**/*.html -
.htmlvalidate.json里至少禁用valid-id（允许重复id用于测试）、no-inline-style（容忍内联样式）、require-sibling-h1（跳过标题层级强校验） - CI脚本中加
--quiet避免大量输出干扰日志，用--format=checkstyle便于Jenkins或GitLab CI解析结果 - 别把
html-validate放在build阶段后执行——它只读HTML文件，应独立为lint:htmlnpm script，在pre-commit或test阶段触发
为什么SonarQube不适合扫前端HTML文件
SonarQube对HTML的支持极其有限：社区版默认不启用HTML分析器，企业版需额外购买SonarHTML插件；即使启用，它只检查基础标签闭合、字符编码、script/style位置等低阶问题，完全不识别语义结构、无障碍属性或框架特有语法（如v-if、ngFor）。更关键的是，它无法处理构建产物中的动态HTML——比如Vite打包后index.html里插入的script标签路径由hash决定，SonarQube静态扫描会误报src属性不存在。
真实场景中，你得先让CI生成dist/index.html，再把它传给SonarQube，但此时HTML已脱离源码上下文（无注释、无条件逻辑、无组件边界），扫描结果既不可信也难修复。与其花时间调通这个链路，不如用html-validate在源码阶段拦截问题。
扫描结果怎么跟开发流程真正挂钩
扫描不是为了生成报告，而是阻止问题进入主干。最容易忽略的一点是：别只在CI里跑，必须同步接入编辑器和提交前检查。
- VS Code装
HTML Validate插件，实时高亮alt缺失、role拼错等问题 - Git钩子用
husky+lint-staged，只对暂存区的HTML文件执行html-validate --fix（注意：--fix仅支持极少数规则，如自动补全alt空值，别指望它重写结构） - CI失败时，错误信息必须带具体行号和规则ID（如
accessibility/heading-order），否则开发者只能靠猜 - 团队要约定哪些规则设为
error（如accessibility/label）、哪些仅为warn（如headings/content），并在README里写清例外申请流程
HTML质量扫描真正的难点不在工具选型，而在规则取舍——语义化和无障碍不是技术问题，是产品责任。没人会为<main></main>标签缺失写bug单，但它直接影响屏幕阅读器用户能否正确理解页面结构。这点容易被跳过，但绕不开。
