innerHTML不能直接用于HTML质量校验，因为它会自动修复语法错误（如补全未闭合标签、修正非法自闭合标签），返回的是浏览器修正后的DOM，而非原始字符串，导致真实问题被掩盖；校验必须基于原始HTML字符串，推荐用DOMParser捕获解析错误，或正则粗筛，同时注意BOM、编码及换行符干扰。
为什么 innerHTML 不能直接用于 HTML 质量校验
因为 innerHTML 会自动修复语法错误（比如闭合缺失的 <li>、补全 </br>），你拿到的已经是“浏览器修正后”的 DOM，根本不是原始代码。想查真实问题，必须处理原始字符串，而不是渲染后的结果。
常见错误现象：document.body.innerHTML 看起来结构完整，但源码里实际存在未闭合标签、非法嵌套或乱码属性值——这些在 innerHTML 里全被抹平了。
- 使用场景：CI 流水线中对模板文件做静态检查，或开发时快速验证手写 HTML 片段
- 关键区别：校验对象是字符串（
string），不是Element或DocumentFragment - 性能影响：用正则粗筛比 DOMParser 全量解析快 3–5 倍，但漏检率高；DOMParser 准确但抛错即中断，需包裹
try/catch
用 DOMParser 捕获真实解析错误
DOMParser 是目前最接近浏览器解析逻辑的原生方案，它不会“修”你的 HTML，而是明确告诉你哪一行哪个字符出问题。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 始终用
text/html类型调用，application/xml会严格报错，连<img>这种自闭合标签都过不去 - 错误信息格式固定：
SyntaxError: Error parsing a name. Name must begin with...，重点看message和lineNumber - 注意兼容性：IE 不支持，Node.js 需搭配
jsdom；现代浏览器中可放心用 - 示例片段：
const parser = new DOMParser(); const doc = parser.parseFromString(htmlString, 'text/html'); const errors = doc.querySelector('parsererror'); // Chrome/Firefox 返回 parsererror 元素，Safari 返回空
自定义脚本库中如何设计可复用的检查函数
不要把所有规则塞进一个函数。按问题类型拆开，比如 checkUnclosedTags、checkInvalidAttributes、checkDuplicatedIds，每个函数只负责一件事，且返回统一格式的错误数组。
关键设计点：
- 输入统一为
htmlString: string，不接受Element或文件路径，避免隐式转换干扰 - 每个检查函数应有可开关的严格模式参数，例如
strict: boolean控制是否把<div class="">当作警告 - 避免全局正则：像匹配
<[^>]+>会误杀注释和 script 内容，必须先剥离<script>、<style>和<!--.*?--> - 性能敏感场景下，用
for循环代替split().filter()，尤其处理 >100KB 的 HTML 文件时差异明显
CI 中集成时最容易被忽略的编码与 BOM 问题
脚本在本地跑通，放到 GitLab CI 就报一堆“Unexpected token”——大概率是文件用了 UTF-8 with BOM 编码，DOMParser 把 BOM 字符当成了 HTML 开头的非法字符。
解决方式很直接：
- 用
Buffer.from(htmlString, 'utf8').toString('utf8')清除 BOM（Node.js） - 前端侧可用
htmlString.replace(/^\uFEFF/, '')快速剔除 - 检查构建机上的 locale 设置，某些 Linux 环境默认用
ISO-8859-1读取文件，导致中文变成乱码再被解析器误判 - Git 配置
core.autocrlf和core.safecrlf，避免换行符混杂引发解析偏移
复杂点在于，BOM 和换行符问题不会出现在错误堆栈里，只会让 lineNumber 错位，最终定位到错误行时发现那行明明写得没问题——这时候得倒回去先验编码。
