不阻塞，但会标记后续dom节点为“未激活”；浏览器解析html时持续创建dom节点，但需等待cssom构建完成才参与样式计算与渲染，故getcomputedstyle()可能返回空、offsetheight可能为0。
link标签是否阻塞DOM解析？
不阻塞，但会标记后续DOM节点为“未激活”。浏览器遇到 <link rel="stylesheet"> 时，主HTML解析器继续推进字符流、创建DOM节点，但这些节点不会立即参与样式计算或渲染——它们被挂起，直到CSSOM构建完成。你仍能用 document.getElementById() 拿到元素，但 getComputedStyle() 可能返回空值，offsetHeight 可能为0。
常见错误现象：脚本在 中执行，调用 querySelector 能取到元素，但读取 clientWidth 却是0。这不是DOM没建好，而是节点还没“激活”。
- 旧版IE/Safari对这种“未激活”状态处理更激进，可能直接跳过部分样式应用
- Chrome/Firefox虽有优化，但若CSS加载超时（如404），通常等待约1秒后才降级激活节点
- 预加载扫描器（preload scanner）会并行下载CSS，但不影响DOM解析线程，也不提前解析内容
link标签如何触发CSSOM构建？
<link rel="stylesheet"> 出现在HTML流中，即刻启动CSS资源发现与加载流程。它不是“等DOM建完再开始”，而是和DOM解析并行启动，但CSSOM构建完成才是渲染树合成的硬性前提。
关键点在于：没有CSSOM，就无法确定某个 <div> 是 <code>display: block 还是 none，也无法计算字体、盒模型、层叠顺序——这些都卡在CSSOM上。
- rel属性必须是
stylesheet（拼错如styleSheet或漏写会被静默忽略） - media属性缺失时默认为
all，浏览器视其为关键资源，强制阻塞首次绘制 - 若设为
media="print"，则不阻塞渲染，但依然触发DNS预解析和TCP预连接 - @import 在CSS文件内会引发串行加载，比多个
<link>更慢，且无法被preload scanner提前发现
link放在body里会发生什么？
DOM已解析到对应位置，CSS才开始加载——此时页面很可能已输出无样式的文本（FOUC），甚至出现布局重排：比如先按默认font-size渲染了一段文字，CSS加载后换成大号字体，导致行高突变、容器撑开、下方元素跳动。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
更隐蔽的问题是资源发现时机延后：DNS预解析、preload优先级提升、HTTP/2服务器推送等机制，在 中的 <link> 都失效。
- 部分浏览器（如旧版Safari）对body内link的支持不一致，样式可能完全不生效
- 即使现代Chrome“修复”了FOUC，也仅靠渲染引擎增量更新，性能代价更高
- SEO工具或Lighthouse可能直接报出“非关键CSS在body中”的警告
- 使用
preload提前拉取CSS时，<link rel="preload" as="style">必须放在最前，否则降级为普通fetch
如何确认CSSOM真正就绪？
没有原生的 cssomReady 事件。监听 <link> 的 load 事件只表示文件下载完成，不代表嵌套的 @import 或字体加载完毕；DOMContentLoaded 也不可靠——它只保证DOM解析完成+同步脚本执行完，但若 <script></script> 在 <link> 后面，则不等待CSSOM。
最实用的兜底方式是组合判断：
- 用
link.addEventListener('load', handler)监听单个CSS加载完成 - 对含
@import的CSS，需在CSS内部用document.fonts.ready或自定义事件通知 - 首屏关键样式建议内联到
<style></style>标签中，绕过网络请求，确保CSSOM与DOM解析共享同一解析线程 - 避免把整份main.css内联——超过10KB会拖慢TTFB，应只提取首屏像素所需的最小规则集（如
.hero,.nav,body基础重置）
CSSOM就绪与否，不取决于link放哪，而取决于资源是否可访问、解析是否完成、以及是否有未决依赖（比如字体、@import、CSS变量引用）。位置只是起点，链路才是关键。
