HTML解析挂起与网页死锁，并非偶发性的简单卡顿，而是浏览器主线程被明确阻塞或持续占用的结果。一旦页面出现白屏、按钮无法点击、滚动冻结超过300毫秒，基本可以判定是解析或执行层面的硬性阻塞。这类问题一旦出现，往往是排查链条的起点。
先来梳理一下，最常见的阻塞场景有哪些。
脚本未加 async 或 defer，HTML 解析必然暂停
脚本一旦出现在 中，尤其是未添加 async 或 defer 属性，浏览器会立即暂停HTML解析进程——等待脚本下载完成并执行完毕后，才继续向下读取。这不是“加载慢”的问题，而是解析器直接停摆。
- 即便脚本只有一行
console.log(1)，HTTP请求本身也会让解析器彻底停摆 这类内联脚本更为直接：不经过网络，但立即执行、立即挂起GUI线程- 移动端对此尤为敏感，超过50ms的单次JS执行就可能造成丢帧；连续执行几乎等于锁死触摸响应
频繁读写DOM会触发回流，渲染线程被挤占
JS引擎与GUI渲染线程天生互斥。在循环中反复读取 offsetHeight、style.left 或调用 document.getElementById()，每次读取都可能触发回流。每次回流都要等JS执行完毕才能渲染，结果就是“点击按钮无反应”“滚动卡成幻灯片”。
- 这是老生常谈但极易踩坑的要点：不要在
for循环中反复查询DOM。建议提前缓存const list = document.querySelectorAll('[id^="item-"]') - 批量修改样式时优先使用
class切换，而非逐个设置el.style.xxx document.write()必须禁用——它会清空当前文档并重建解析器，强制重排，现代浏览器已将其标记为废弃
长任务未拆分，主线程被持续霸占
浏览器设定了一个50ms的阈值——一旦单个函数执行超过50ms，就会被判定为“长任务”，用户的所有交互事件（点击、输入）会被压在队列尾部，直到该任务完成。常见于数据处理、字符串匹配、深度遍历等场景。虽然不报错，但页面会彻底失联。
- 使用
setTimeout或requestIdleCallback拆分任务，避免单次执行超过50ms - 对大型数组执行 map/filter 前，先确认是否真的需要全量同步处理；可考虑分片（chunking）或直接交给 Web Worker
- 警惕第三方SDK的初始化逻辑——许多统计或客服脚本在
init()中执行DOM遍历和计算，一上来就占满主线程
未闭合标签，迫使整个DOM树被浏览器强行重排
一个遗漏的
footer 跑进 header，第一反应是去修改 header 末尾，其实问题可能出现在前面第三个 - 打开 DevTools → Elements 面板，观察节点边缘是否有红色高亮或灰色半透明提示（Chrome/Edge 的非法嵌套标记）
- 右键 → Edit as HTML 修改一行，整个结构发生“跳变”→ 说明原始结构已被浏览器强行修复过
- 特别注意：
table、ul、ol内部只接受特定子标签（如tr、li），插入div或p会直接触发重排，DOM树即刻失真
真正令人头疼的，是那些既不报错也不警告的阻塞。例如一个未加 defer 的第三方脚本，恰好卡在首屏DOM构建中途；或者一段看似无害的循环读取 clientWidth，却在低端设备上将帧率拉低至5fps。这类问题不会出现在Console中，只能依靠Performance面板里 Parse HTML 被 Evaluate Script 截断的痕迹来定位。细节魔鬼往往藏身于此。
