HTML解析无编译环节，仅通过线性tokenization与DOM构建实现，依赖状态机分词、容错修复，不生成字节码或AST；错误由静态分析（如htmlhint）或运行时DOM拦截提前发现。
HTML 没有“编译”环节，所谓“底层编译”是误解。浏览器解析 HTML 是线性 tokenization + 构建 DOM 树的过程，不生成中间字节码，也不做类型检查或语法重写。试图从“编译层”修复动态 HTML 缺陷，方向错误，会浪费大量时间排查根本不存在的环节。
为什么不能像 JS 那样“编译时检测”HTML？
HTML 解析器（如 Blink、WebKit 的 HTMLTokenizer）只做三件事：分词（tokenize）、构建 DOM、容错修复（比如自动闭合 <p>、忽略非法嵌套）。它不会报错中断，也不会生成 AST 供后续规则扫描——除非你额外引入静态分析工具。
- 浏览器控制台里看到的
Unclosed tag或Unexpected end tag是解析器日志，不是编译错误，更不阻断渲染 -
document.write()或innerHTML = '...'拼接的字符串，是在运行时直接 feed 给解析器，跳过任何预检 - 服务端模板（如 EJS、Handlebars）输出的 HTML，其“生成阶段”也无校验逻辑，除非你主动加 lint 步骤
真正起作用的是静态分析和注入拦截
能提前发现问题的，只有两类机制：一是构建时/保存时的静态扫描，二是运行时对 DOM 操作的封装拦截。它们都不依赖“编译”，但效果明确。
- 用
htmlhint在 CI 中跑htmlhint "**/*.html"，可捕获attr-lowercase、tag-pair等 40+ 规则问题 - 在框架层封装
setInnerHTML，内部先用DOMParser尝试解析字符串，捕获SyntaxError后降级处理或上报 - VS Code 安装
HTMLHint插件 + 配置.htmlhintrc，保存即标红<img src=logo.png>（缺引号）这类低级错误
动态 HTML 最常踩的三个坑
多数质量缺陷集中在运行时拼接环节，而非“编译”或解析阶段。以下问题高频出现，且容易被误认为是环境或浏览器 bug：
立即学习“前端免费学习笔记（深入）”；
-
innerHTML = '<div class="item">' + data.title + '</div>'—— 若data.title含<或"，直接破坏 DOM 结构，必须escapeHTML()处理 - 使用
document.createElement('div').innerHTML = htmlString创建片段时，脚本标签（<script>）不会执行，但内联事件（onclick）仍会被解析，存在 XSS 风险 - 通过
fetch加载 HTML 片段后调用element.insertAdjacentHTML('beforeend', res.text)，若后端返回含 BOM 或 UTF-8 变体编码，可能导致标签解析错位
真正的关键点不在“怎么编译”，而在“谁负责校验输入”和“在哪一环切断污染”。动态 HTML 的质量防线，必须设在字符串拼接之前、插入 DOM 之后、以及构建流程的出口处——而不是幻想一个不存在的编译器替你兜底。
