dom解析不慢，真正瓶颈是浏览器等待cssom就位才构建渲染树，且js可能读取样式或修改dom，导致加载顺序与时机错配引发白屏。
DOM解析本身不慢，真正卡住页面的是浏览器主动插入的等待逻辑——它必须等CSSOM就位才敢构建渲染树，而JS又可能随时读取样式或改写DOM，所以加载顺序和时机错配才是核心瓶颈。
为什么CSS加载不阻塞DOM解析，却让首屏白屏这么久？
CSS加载走的是独立线程，<link rel="stylesheet">不会中断HTML parser，DOM树照常构建。但浏览器在生成渲染树（Render Tree）前，必须把DOM树和CSSOM树合并，而CSSOM没齐，渲染树就建不了——用户看到的就是白屏或闪动。
- 现象：Lighthouse报“Eliminate render-blocking resources”，
DOMContentLoaded可能很快，但load事件或首帧绘制（FP/FCP）严重延迟 - 关键点：不是DOM没建完，是浏览器“不敢画”——哪怕DOM早建好了，CSS文件还在磁盘读取中，它就停在渲染准备阶段
- 本地大文件尤其明显：20MB HTML + 外部CSS，在机械硬盘上CSS读取可能占去4–6秒，这期间主线程空转，但页面就是不显示
script的defer和async用错，会直接破坏DOM就绪时机
两者都让脚本不阻塞HTML解析，但执行时机天差地别。选错一个，document.querySelector就拿不到元素，或者getComputedStyle返回空值。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
defer：脚本按文档顺序下载，DOM解析一结束、DOMContentLoaded触发前执行；适合操作DOM的初始化代码 -
async：谁先下完谁先执行，顺序不确定；只适合完全无依赖的脚本（如统计埋点），且不能假设document.body已存在 - 内联脚本（
<script>...</script>）默认同步执行，若它不操作DOM，可加defer；若必须同步又怕阻塞，就拆成外部文件再加defer
DOM树深度超6层时，getComputedStyle和重排开销会指数级上升
浏览器计算样式要递归遍历祖先节点匹配选择器，树越深，路径越长。实测深度从4升到8，getComputedStyle耗时翻倍；深度达12，低端机单次调用卡顿超80ms。
- 常见坑：
body > div > div > div > .item这种强嵌套选择器，在深层DOM里查100个节点，总耗时比平铺结构高30%以上 - 查DOM时务必缓存引用：
const items = document.querySelectorAll('.item');，别在循环里反复调用 - 避免在
scroll或resize回调中读写offsetTop/offsetLeft——紧挨着样式修改就会触发强制同步布局
大型本地HTML页面中，外部CSS比内联样式慢几十倍的根本原因
不是CSS本身慢，是I/O事务多了一轮。外部CSS要走“HTML解析 → 遇到<link> → 暂停 → 发起文件读取 → 解析CSS → 恢复渲染”全流程；而内联样式随HTML一并解析，零额外请求。
- 20,000条记录的本地HTML：外部CSS加载+解析约6秒，内联样式0.1秒内完成
- 关键差异在加载时间（Load Time），不在渲染时间（Render Time）——后者两者几乎无差别
- 但内联样式不可缓存、无法复用、不利于维护，上线项目慎用；仅适合离线报告、一次性导出页等场景
真正难处理的不是单个技术点，而是DOM结构、资源加载顺序、JS执行时机三者交织形成的竞态——比如一个defer脚本里调用了getComputedStyle，而它依赖的CSS刚好被标记为preload但尚未解析完毕，这时返回的就可能是不完整值。这类问题不会报错，只会让视觉表现偶尔错乱，极难复现和定位。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
