放不一定管用，因浏览器流式解析中CSS加载、CSSOM构建与JS执行存在时序竞争，需验证document.styleSheets、getComputedStyle或用requestAnimationFrame兜底。
为什么 <link> 放
浏览器解析 HTML 是流式进行的，即使 <link rel="stylesheet"> 写在 里、且在 <script></script> 标签之前，样式仍可能被脚本阻塞或延迟应用——尤其当 CSS 文件体积大、网络慢，或脚本用了 document.write、同步 XHR 等破坏性操作时。
关键不是“位置对不对”，而是“浏览器是否已解析并应用了样式规则，才执行 JS”。常见错误现象：Uncaught TypeError: Cannot read property 'offsetTop' of null 或元素尺寸为 0，本质是脚本读取了尚未渲染完成的 DOM 样式。
- 确保
<link>没有加media="print"或其他不匹配当前环境的条件（会延迟加载） - 避免在
<link>上使用onload回调后立刻执行依赖样式的 JS —— 它只表示文件下载完成，不保证 CSSOM 构建完毕 - 如果用了
rel="preload"提前拉取 CSS，必须配合as="style"和onload中的document.createElement('link')注入，否则不会触发样式应用
如何验证 CSS 是否真正在脚本执行前就绪
不能只看 HTML 顺序，得看浏览器行为。最直接的方式是检查 document.styleSheets 和渲染树状态。
- 在脚本开头加
console.log(document.styleSheets.length)，对比预期数量；若少于实际<link>数，说明某些 CSS 还没加载/解析完 - 用
getComputedStyle(document.body).backgroundColor测试一个明确由 CSS 设置的属性，如果返回默认值（如rgba(0, 0, 0, 0)）而非你设的色值，大概率样式未生效 - Chrome DevTools 的
Rendering→Paint flashing可观察重绘范围；若脚本运行后才出现大面积闪烁，说明样式延迟应用
DOMContentLoaded 也不保险？那该等什么
DOMContentLoaded 表示 HTML 解析完成、DOM 构建完毕，但不保证 CSSOM 已就绪、更不保证样式已应用于布局。很多开发者误以为它比 window.onload 更早、更“轻量”，结果照样踩坑。
立即学习“前端免费学习笔记（深入）”；
- 真正可靠的时机是
document.fonts.ready（仅限字体相关）或监听document.addEventListener('readystatechange', ...)并检查document.readyState === 'complete'—— 这个状态才意味着所有资源（含 CSS）加载、解析、样式应用全部完成 - 更务实的做法：把依赖样式的逻辑包裹进
requestAnimationFrame第二帧，例如requestAnimationFrame(() => requestAnimationFrame(() => { /* 读 offsetTop 等 */ }))，能大概率避开样式未应用的窗口期 - 如果必须同步执行，考虑用
CSS.supports()配合getComputedStyle做兜底判断，而不是无条件假设样式已就位
现代方案：rel="preload" + onload 注入的细节陷阱
这是目前最可控的提前加载+可控应用方式，但容易漏掉关键拼接步骤。
<link rel="preload" href="main.css" as="style" onload="this.onload=null;this.rel='stylesheet'"> <noscript><link rel="stylesheet" href="main.css"></noscript>
上面写法看似简洁，但有三个易忽略点：
-
this.onload=null必须放在赋值rel之前，否则可能触发两次加载（某些浏览器会因rel变更重新请求） - 如果 CSS 文件 404，
onload不会触发，也不会降级到<noscript></noscript>（因为 JS 启用状态下<noscript></noscript>被忽略），需额外加onerror处理 -
as="style"缺失会导致浏览器按fetch普通资源处理，不提升优先级，失去预加载意义
复杂点从来不在“放哪”，而在“怎么确认它真起了作用”。哪怕顺序对了，没验证加载状态、没兜底重试、没测过弱网，就等于没做。
