结论：自研轻量级html扫描工具没必要从零写解析器，用htmlhint做底层引擎+封装cli/ui层，3天内就能交付可落地的定制版。真正耗时的不是“能不能扫”，而是规则适配、错误定位精度、和现有工程链路的咬合。
HTMLHint 做底层引擎 + 封装 CLI/UI 层，3 天内就能交付可落地的定制版**。真正耗时的不是“能不能扫”，而是规则适配、错误定位精度、和现有工程链路的咬合。
为什么别重写 HTML 解析器
HTML 的语法边界模糊（比如标签嵌套容错、自闭合标签处理、属性值引号省略），Zombie DOM 或正则匹配极易漏报/误报。官方推荐的 parse5 或 htmlparser2 已经足够成熟，但你仍需处理 AST 节点映射、行号列号还原、错误上下文截取——这些加起来比业务规则开发多出 2–3 倍工时。
而 HTMLHint 底层就基于 parse5，暴露了完整的 AST 和 rule context，且自带 40+ 权威规则（attr-lowercase、tag-pair、id-unique 等），直接复用能绕过 90% 的语法陷阱。
- 它不校验渲染结果，只校验结构合法性，正好匹配“代码质量”而非“运行时行为”
- 所有规则可开关、可配置参数（比如
attr-no-duplication支持忽略特定属性） - 错误对象带
line、col、message、ruleId，方便做跳转或高亮
HTMLHint 规则定制的三个关键动作
默认规则集偏保守，真实项目常需收紧或放宽。改规则不是改 JSON 配置那么简单：
- 禁用某条规则（如允许
<img>缺alt）：在.htmlhintrc中设"attr-alt-require": false，但要注意这会让accessibility类规则整体失效 - 扩展规则逻辑（如要求所有
class值必须来自预设列表）：需写自定义 rule，导出create函数，接收ast和report，在Attribute节点上做字符串匹配 - 动态规则（如禁止在
production环境中出现console.log注释）：不能靠静态分析，得在 CLI 层加预处理，用正则提取注释内容再校验
CLI 与 Web UI 的分工陷阱
很多人想做一个“带界面的扫描工具”，结果卡在 UI 渲染性能上——一次扫描可能返回上千条错误，全量渲染 DOM 直接卡死浏览器。
- CLI 版优先支持
--fix自动修复（仅限格式类问题，如引号标准化、标签闭合），用htmlhint --fix即可，无需自己实现 - Web UI 必须做分页或懒加载：只渲染前 50 条错误，并提供“按规则类型筛选”“按文件路径过滤”入口
- 别在浏览器里跑完整扫描：把
HTMLHint实例放在 Worker 中，主线程只收错误数组，避免阻塞 UI - 错误定位要精确到字符：
HTMLHint的col是 UTF-16 索引，若页面含 emoji 或宽字符，直接用textContent.substring(0, col)会错位，得用Array.from(text).slice(0, col).join('')
和构建流程集成时最常漏掉的一环
多数人只想到 npm run lint:html，但线上部署前的静默检查才最关键。
- CI 中加
htmlhint "**/*.html" --format=checkstyle > checkstyle.xml，再用 SonarQube 或 CodeClimate 解析，才能进质量门禁 - Webpack/Vite 插件需监听
.html文件变更，但注意：Vite 的transformIndexHtml钩子拿到的是已注入 script 的最终 HTML，不是源码，应改用handleHotUpdate读原始文件 - VS Code 插件若用 Language Server Protocol（LSP），必须重写
textDocument/diagnostic响应逻辑，因为HTMLHint默认不支持增量校验，每次都要全量 parse
真正的轻量，不在于代码行数少，而在于每处定制都直击协作痛点：开发者要的是“改完立刻看到哪行错了”，而不是“又弹出一个看不懂的 ruleId”。HTMLHint 的可插拔设计已经覆盖了 80% 场景，剩下 20% 的缝合工作，才是自研价值所在。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
