htmlhint配置文件不生效的根本原因是规则名错误、配置路径不对或vs code未读取到正确位置的.htmlhintrc；它只认当前命令执行目录下的配置，不递归查找，且规则名须严格匹配官方文档。
HTMLHint 配置文件为什么总不生效？
根本原因通常是规则名写错、配置路径不对，或 VS Code 没读到正确位置的 .htmlhintrc。HTMLHint 不会自动向上级目录递归查找配置文件，它只认当前执行命令所在目录下的配置。
- 确保
.htmlhintrc和你要检查的 HTML 文件在同一目录，或在项目根目录（运行htmlhint时 cwd 是项目根） - 规则名必须完全匹配官方文档，比如
attr-lowercase不能写成attr_lowercase或attrLowercase - VS Code 扩展默认只检查打开的文件，不自动扫描整个工作区；需右键文件 → “HTMLHint: Run Linter” 才触发全规则校验
- 如果用 Webpack 或 Gulp 集成，注意插件版本是否兼容 ——
htmlhint-webpack-plugin@2.x不支持.htmlhintrc中的extends字段
AI 工具真能替代人工审 HTML 吗？
能覆盖 70%～80% 的结构性和规范性问题，但无法替代对业务语义和交互意图的判断。比如通义灵码或 InsCode AI IDE 可以指出 <img> 缺少 alt，也能建议把 <div class="btn"></div> 改成 <button></button>，但它不知道这个按钮是“提交订单”还是“取消订阅”，也就无法验证 aria-label 是否准确反映用户操作后果。
- AI 擅长检测：标签闭合、属性拼写、DOCTYPE 位置、字符编码声明、重复 ID、内联样式滥用
- AI 容易误报：动态插入的 DOM（如 React 渲染后生成的结构）、模板语法（
{{#if}}等）会被当作非法 HTML 解析 - 真正需要人盯的点：语义层级是否符合内容逻辑（例如
<h2></h2>是否真的该是二级标题）、ARIA role/state 是否与交互状态同步、表单验证提示是否可访问
W3C 验证器 vs HTMLHint：什么时候该用哪个？
W3C 验证器是合规性终点，HTMLHint 是开发过程中的守门员。前者告诉你“这段 HTML 是否符合标准”，后者告诉你“这段 HTML 是否符合团队约定”。
- 上线前必跑 W3C：它严格按 HTML5 规范校验，能发现
<bdi></bdi>使用不当、rel值不在白名单等深层合规问题 - 日常开发用 HTMLHint：你可以关掉
doctype-html5规则来容忍遗留系统里的 XHTML 文档声明，也可以开inline-style-disabled强制外联 CSS —— 这些都是 W3C 不管的工程约束 - CI/CD 里建议两者都跑：W3C 防止语法硬伤，HTMLHint 防止风格滑坡；但注意 W3C 验证需网络请求，不适合高频本地构建
语义化标签被 AI 标注错怎么办？
AI 做语义标注依赖 DOM 结构 + 文本 + 上下文，但真实页面常有干扰项：CSS 隐藏内容、JS 动态替换、服务端模板注释。比如 <!-- header --><div class="wrap"> 这类注释会让模型误判为真实语义节点。<ul>
<li>优先清理无意义的 HTML 注释和空标签（<code><div></div>），它们是 AI 语义识别的最大噪声源
class="main-nav" 不如直接用 <nav></nav>；AI 很难区分这是开发者偷懒还是有意为之MutationObserver 监听机制 —— 否则它只分析初始 HTML，漏掉 JS 渲染后的语义结构真实项目里最常被忽略的，不是规则设得多不多，而是谁来决定哪些规则可以关、哪些必须死守。一套配置在测试环境跑得通，上线后可能因 CDN 缓存旧 HTML 或 SSR 渲染差异而失效。
