HTML解析引擎卡住是因为单线程自上而下解析时，遇未闭合标签、嵌套过深（≥7层）、<meta charset>位置靠后、内联大脚本或空<div>等，会触发容错修复、重载重绘或阻塞等待，导致DOM构建中断或耗时倍增。
HTML本身不执行逻辑，但它是浏览器解析引擎工作的起点——写法不对，解析就卡在第一行。
为什么解析引擎会卡住？
浏览器解析HTML是单线程、自上而下进行的。遇到 <script> 就暂停，遇到未闭合标签或嵌套过深的 <div> 就反复回溯修复，遇到编码声明靠后就重载重绘。这些都不是“慢”，是解析引擎被你写的HTML主动拖住了。
- DOM树深度超过6层时，低端安卓WebView解析耗时可能翻倍
-
<meta charset="utf-8">不在前1024字节内，浏览器会先按latin1乱解一遍再重载 - 连续3层以上空
<div class="">仍要进DOM树，白占内存和样式计算开销
怎么让解析引擎跑得顺？
核心是减少它“猜”和“修”的动作，给它干净、扁平、语义明确的输入。
- 用
<header>、<nav>、<main>替代<div class="wrapper"><div class="inner"><div class="content"> - Flexbox/Grid布局天然减少嵌套，5层
<div>套娃 → 1层<section>+display: grid - 服务端渲染（SSR）时别生成大量空节点，
<div></div>和<div class=""></div>都不是“没用”，它们是真实DOM节点
哪些HTML写法会让解析引擎“误判”？
不是所有合法HTML都适合快速解析。有些写法浏览器能容错，但代价是额外解析周期。
立即学习“前端免费学习笔记（深入）”；
- 残缺标签如
<p>未闭合段落 <img src="test.jpg">：HTMLParser能处理，但需启动容错模式，比标准流慢15–30% - 内联大段JS（比如
<script>for (let i = 0; i < 10000; i++) {...}</script>）：即使不依赖DOM，V8也要先解析整段字符串，比创建元素慢3–5倍 - 用
innerHTML = '<div>...</div>'拼接长模板：触发完整HTML词法+语法分析，而非直接DOM操作
解析阶段最容易被忽略的性能点
很多人盯着JS执行时间，却忘了浏览器在执行JS前，已经花了几百毫秒在解析你那2000行的HTML上。尤其要注意：
-
<meta charset>必须紧贴<head>开头，不能被<title>或注释挡住 - 避免在
<head>里放非关键<script src>—— 它不光阻塞解析，还可能提前触发DNS预查，挤占首屏资源带宽 - 服务端返回的HTML不要带开发用注释（
<!-- debug: xxx -->），压缩工具未必能清干净，而解析引擎照单全收
