html解析引擎卡住是因为单线程自上而下解析时，遇未闭合标签、嵌套过深（≥7层）、位置靠后、内联大脚本或空等，会触发容错修复、重载重绘或阻塞等待，导致dom构建中断或耗时倍增。
HTML本身不执行逻辑，但它是浏览器解析引擎工作的起点——写法不对，解析就卡在第一行。
为什么解析引擎会卡住？
浏览器解析HTML是单线程、自上而下进行的。遇到 <script></script> 就暂停，遇到未闭合标签或嵌套过深的 <div> 就反复回溯修复，遇到编码声明靠后就重载重绘。这些都不是“慢”，是解析引擎被你写的HTML主动拖住了。<ul>
<li>DOM树深度超过6层时，低端安卓WebView解析耗时可能翻倍</li>
<li>
<code><meta charset="utf-8"> 不在前1024字节内，浏览器会先按latin1乱解一遍再重载
<div class=""> 仍要进DOM树，白占内存和样式计算开销<h3>怎么让解析引擎跑得顺？</h3>
<p>核心是减少它“猜”和“修”的动作，给它干净、扁平、语义明确的输入。</p>
<ul><li>用 <code><header></header>、<nav></nav>、<main></main> 替代 <div class="wrapper"><div class="inner"><div class="content"><li>Flexbox/Grid布局天然减少嵌套，5层 <code><div> 套娃 → 1层 <code><section></section> + display: grid<div></div> 和 <div class=""></div> 都不是“没用”，它们是真实DOM节点哪些HTML写法会让解析引擎“误判”？
不是所有合法HTML都适合快速解析。有些写法浏览器能容错，但代价是额外解析周期。
- 残缺标签如
<p>未闭合段落 <img src="test.jpg"></p>：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>必须紧贴开头，不能被<title></title>或注释挡住 - 避免在
里放非关键<script src></script>—— 它不光阻塞解析，还可能提前触发DNS预查，挤占首屏资源带宽 - 服务端返回的HTML不要带开发用注释（
<!-- debug: xxx -->），压缩工具未必能清干净，而解析引擎照单全收
