HTML解析无异常机制，错误由浏览器静默修正；检测应聚焦开发期静态校验（如html-validate）和运行时DOM结构验证，而非尝试捕获不存在的HTML异常。
HTML 本身没有“异常”概念，所谓“动态DOM异常引发的HTML代码质量检测”，本质是误把 DOM 操作失败、资源加载失败或解析静默修正，当成可捕获的错误去设计机制——这条路从起点就走偏了。
为什么 window.onerror 和 try-catch 对 HTML 解析无效
浏览器解析 HTML 是独立于 JS 执行的阶段，遇到未闭合标签、非法嵌套（如 <p><div></div></p>）、错位 <script> 等问题时，不会抛出 JS 异常，也不会触发 window.onerror 或 try-catch。它直接按 HTML5 规范静默纠错：拆开、补全、丢弃、重排 DOM 树。你看到的 Elements 面板结构，已经是修正后的结果，和源码不一致。
常见误判场景：
- 用
document.querySelector('p div')查不到元素，以为是“脚本报错”，其实是浏览器早把<div>踢出了<p>，DOM 结构已变 - 监听
window.onerror期望捕获<img src="404.jpg">失败 —— 它不触发，必须用img.onerror - 对内联 HTML 字符串调用
DOMParser().parseFromString(htmlStr, 'text/html')后加try-catch—— 它永远返回 Document，不会 throw
真正能反映 HTML 质量的只有两类信号
一类在开发期，一类在运行时；但都不是“异常捕获”能覆盖的。
立即学习“前端免费学习笔记（深入）”；
开发期信号（强推荐）：
- 用
html-validateCLI 或 VS Code 的vscode-htmlhint插件，在保存/提交时检查 content model 违规，例如Element div not allowed as child of element p - CI 流程中接入
curl -F "uploaded_file=@index.html" https://validator.w3.org/nu/，自动阻断含嵌套错误的部署
运行时信号（弱辅助，仅限极端情况）：
- 动态插入 HTML 后，检查
document.body.children.length === 0 && htmlStr.trim()，提示“字符串解析为空”，说明输入极可能严重违法（如全是未闭合标签） - 执行
document.querySelectorAll('*').forEach(el => { if (!el.parentElement) console.warn('孤立元素:', el); })，揪出被浏览器踢出 DOM 树的节点（常见于<ul><div></div></ul>）
DOM 操作失败 ≠ HTML 错误，别混淆层级
很多你以为是“HTML 质量差”导致的问题，实际是 JS 执行时机或 DOM 状态管理的问题：
-
document.getElementById('el').innerText = 'x'报TypeError，不是 HTML 写错了，而是元素还没加载到 DOM 中 —— 应检查document.readyState或用DOMContentLoaded -
new Audio('broken.mp3').play()失败，不是 HTML 语法问题，是媒体资源加载或解码失败，需监听error事件，而非 catch - Selenium 报
StaleElementReferenceException，不是页面 HTML 不规范，是元素被 SPA 框架重新渲染了，该换定位策略或加显式等待
把 DOM 操作异常反推为 HTML 质量问题，就像把汽车熄火归咎于挡风玻璃没擦干净——方向错了，越用力查越偏。
如果真要建“自研检测”，只做一件事就够了
不要试图在运行时捕获“HTML 异常”，那不存在。唯一靠谱的自研点，是把 W3C Validator 的校验能力封装成轻量服务或 CLI 工具，接入本地开发流和 CI 流程，让它在 HTML 文件落地前就报出 Element img is not closed 这类硬性错误。所有其他“动态捕获”方案，最终都会沦为对浏览器静默行为的徒劳猜测。
