html语法错误不能只靠浏览器自动修复，因为不同引擎修复策略不一致导致dom结构差异、js选择器失效、无障碍缺陷被掩盖，且错误可能被隐藏至dom深层引发静默故障。
HTML语法错误为什么不能只靠浏览器自动修复？
浏览器确实会容错处理很多HTML错误，比如自动闭合缺失的 、忽略未引号包裹的属性值，但这恰恰是问题根源。不同引擎（Chrome/Firefox/Safari）对同一错误的修复策略不一致，导致DOM结构在各环境里实际解析结果不同——你看到页面“能显示”，不代表 document.querySelector 能稳定取到元素，也不代表屏幕阅读器能正确朗读语义。更隐蔽的是，这类修复常把错误“藏”进DOM树深层，比如把本该在 <header></header> 内的 <nav></nav> 错位到 外层，后续JS操作可能静默失败。
- W3C验证器报错
End tag for element 'p' seen, but there were open elements.时，说明存在嵌套断裂，浏览器可能已重排DOM，但你的CSS选择器仍按原结构写，必然失效 -
img标签漏写alt属性，在无障碍检测中直接判为严重缺陷，而浏览器完全不提示 - 自定义属性如
data-user-id拼错成data-usre-id，JS里用dataset.userId取不到值，控制台却无报错
如何把W3C验证集成进CI/CD流水线？
人工粘贴代码去 https://validator.w3.org/ 验证显然不可行。真正落地的做法是调用其API或使用本地等效工具，避免网络依赖和限流。推荐用 html-validate（非HTMLHint），它内置W3C校验规则且支持自定义插件，能输出机器可读的JSON报告。
- 安装：执行
npm install --save-dev html-validate，然后在项目根目录创建.htmlvalidate.json - 关键配置项必须包含：
"w3cvalidate"（启用W3C标准检查）、"no-inline-style"（防样式污染）、"require-alt-attribute"（强制无障碍） - CI脚本中加入：
npx html-validate --output-format json --output-file report.json src/**/*.html，再用简单脚本解析report.json中的errorCount决定是否阻断构建 - 注意：不要用
htmlhint的w3cvalidate规则，它只是模拟，实际不连W3C服务器，误报率高
自愈机制不是改代码，而是建反馈闭环
发现错误后自动“修复”HTML容易引发更大风险——比如把 <div class="btn"> 错误地补成 <code>
