<style>标签必须放在<head>中，因浏览器流式解析HTML，若置于<body>会导致首屏元素渲染完成后再注入样式，引发闪屏或错乱；Chrome和Safari初始渲染阶段不保证其及时生效。
为什么
浏览器解析 HTML 是流式的，<style>必须出现在 <head> 中，否则首屏关键元素（比如 .hero-title、.cta-button）可能已经渲染完成，样式才开始注入——结果就是闪屏或错乱。Chrome 和 Safari 在初始渲染阶段不保证对 <body> 里 <style> 的及时应用，哪怕它最终“生效”了，也属于不可靠行为。
常见错误：
- 把
<style>放在</body>前，以为“越晚执行越安全”——实际是白屏风险放大器 - 用 JS 动态创建
<style>并 append 到document.body——首次绘制时无样式可用 - 在 SSR 模板中把 critical CSS 插入到
<body>开头，但未同步触发document.styleSheets更新逻辑
内联Critical CSS时，<style>里哪些写法会直接失效
<style> 是纯 CSS 容器，任何非标准 CSS 写法都会导致整条规则被忽略，甚至中断后续解析。
务必避开：
立即学习“前端免费学习笔记（深入）”；
-
@import url("non-critical.css")—— 触发额外阻塞请求，且路径解析不可靠，容易 404 - 未转义的 HTML 字符，比如注释里写了
<div>却没用—— 浏览器提前闭合 <code><style>标签 - 漏写大括号或分号，如
.hero-title { color: #333 font-size: 1.5rem }—— 第二条声明常被静默丢弃 - 含
url()的背景图或字体引用，且资源未预加载或跨域未配 CORS —— 整条规则延迟应用，甚至卡住 CSSOM 构建
内联体积怎么控制在真正有效的范围内
不是“越小越好”，而是“刚好够首屏渲染”。工具提取的 critical CSS 常含冗余，手动删减又易漏，需结合真实验证。
实操建议：
- 用
crtters或vite-plugin-critical提取后，先在 DevTools Network 面板勾选Offline刷新 —— 若.hero-title文字、按钮颜色、导航栏高度都正常，说明提取靠谱 - 体积目标按网络环境分级：移动端弱网下优先压到 1KB 以内；HTTP/2 环境可放宽至 14KB，但超过后会触发额外 RTT
- 别把
@font-face或动画关键帧硬塞进内联<style>—— 它们不参与首屏布局，却拖慢 CSSOM 解析 - 内联内容不参与缓存，所以
.hero-title这类高频复用样式，若同时出现在多个页面，应评估是否值得拆成独立缓存文件 + preload
非关键 CSS 通过 <link> 加载时，<style> 该怎么配合
<style> 不只是放 critical CSS 的容器，它还能和 <link> 协同解决 FOUC 和媒体查询失效问题。
典型配合方式：
- 用
<link rel="stylesheet" href="non-critical.css" media="print" onload="this.media='all'">—— 浏览器默认跳过加载，等资源就绪再切换，避免阻塞 - 若需响应式支持（比如暗色模式），不要删掉
dark-theme.css的<link>，而是在<style>里预留基础媒体查询钩子：@media (prefers-color-scheme: dark) { :root { --bg: #111 } } - 禁止在
<style>里写@import引入非关键 CSS —— 它强制串行加载，实测拖慢 FCP 300ms+ - 动态主题切换场景下，用
document.styleSheets替代反复插入/删除<style>标签，避免重排重绘抖动
Recalculate Style 时间轴，才能告诉你那几行 <style> 到底有没有真正起效。 
