必须用npx htmlhint "*/.html" --quiet在ci中阻断问题，因--quiet确保错误时返回非0退出码；github actions需加if: always()捕获失败；基础规则如attr-lowercase设为error，风格类规则设warn；动态html需puppeteer预渲染后检查。
不能只靠人工抽查或上线后救火，必须让HTML质量检查在代码提交前就卡住问题——否则每次发版都像在赌“这次有没有漏掉一个没闭合的<div>”。
<h3>怎么用HTMLHint在CI流程里真正卡住问题</h3>
<p>很多人把<code>htmlhint加进CI只是跑一下、输出点日志，结果PR照常合并，问题照旧上线。关键不是“有没有运行”，而是“是否阻断”。
- 必须用
npx htmlhint "**/*.html" --quiet，去掉--quiet会导致CI误判退出码（即使有错误也返回0） - 在GitHub Actions中，
run步骤后要加if: always()才能捕获失败，否则默认跳过后续步骤，起不到拦截作用 - 规则配置里
"attr-lowercase": true这类基础项必须启用，但像"id-class-value": "dash"这种风格类规则建议设为warn而非error，避免阻塞非关键修改 - 对动态生成的HTML（如CMS模板、SSR输出），需配合
puppeteer预渲染后再检查，否则htmlhint只扫静态文件，漏掉真实DOM结构问题
为什么W3C验证器不能替代本地静态检查
https://validator.w3.org/能发现嵌套错误和废弃属性，但它查不了团队内部约定——比如强制使用<ui-card></ui-card>组件而非原生<div class="card">，也做不到毫秒级反馈。
<ul>
<li>W3C验证器依赖HTTP响应，无法检查本地未部署的分支代码</li>
<li>它不支持自定义规则，像“所有按钮必须带<code>aria-label”或“禁止在外写<script></script>”这类业务约束无法落地
htmlhint保存时自动校验，比等CI跑完再返工快10倍修复建议怎么才不算纸上谈兵
很多工具报错只说“img missing alt”，但不告诉你该填什么。生产环境需要的是可执行的修复路径。
- 对缺失
alt的图片，优先从title属性或附近<h2></h2>文本提取语义，而不是一律填“图片” - 遇到
<table>布局，不要只标“建议改用CSS Grid”，而应生成对比代码块：<code><div class="grid">...</div>vs 原<table> <li>自动修复功能慎用：像补闭合标签这种操作，<code>html-minifier可能破坏内联JS逻辑，必须加白名单开关，仅对纯结构文件开启 - 修复建议要带上下文行号，例如“第47行
<p></p>缺少闭合，上一行<div id="main">未闭合导致嵌套错乱” <p>真正的闭环不在工具链多华丽，而在每次<code>git push后，开发者手机收到钉钉提醒：“product.html第89行<nav></nav>未闭合，已自动隔离该文件，合并被拒绝”。这要求规则引擎能区分P0硬性阻断项和P2优化建议项，且所有判断必须留痕——因为下次审计时，你得说清为什么允许某次绕过alt-require规则。
