关键CSS内联仅在精准提取、体积可控、构建闭环时有效；盲目内联会增大HTML、破坏缓存、引发样式错乱。须用critters或critical工具结合Puppeteer模拟真实设备提取，处理@import和CSS-in-JS限制，避免内联字体、动画及全局重置等无效规则。
关键CSS内联确实能缩短首屏时间，但只在精准提取、体积可控、构建流程闭环的前提下成立；盲目内联反而让HTML变大、缓存失效、样式错乱风险陡增。
怎么提取真正影响首屏的CSS规则
不能靠“猜”或截取main.css前100行。首屏样式取决于实际 viewport 尺寸、媒体查询匹配状态、伪类（如:hover）是否触发，以及暗色模式等系统偏好。
- 用
critters（Webpack/Vite 插件）或criticalCLI 工具驱动 Puppeteer，在模拟真实设备尺寸下访问首屏路径，捕获被应用的规则 - 手动验证：DevTools → Network → Disable cache → 刷新，确认外链
styles.css请求是否完全消失（不该发起） - 若源 CSS 含
@import，需先用postcss-import展开，否则critters默认不处理 - 对 CSS-in-JS 生成的动态类名（如
jsx-abc123），工具识别率低，建议改用运行时注入而非内联
内联后HTML体积和缓存怎么不崩
内联块没有独立缓存，HTML 文件一变，整个页面就失效。线上最常出问题的是构建漏步骤或CDN缓存污染。
- 关键CSS必须作为构建必经环节输出为单独文件（如
critical.css），再由脚本读取内容注入模板，而非硬编码在HTML里 - HTML 文件名加哈希（如
index.abc123.html），避免CDN返回旧版本 - CI 流程中必须校验：生成的内联CSS是否包含
@media (prefers-color-scheme: dark)（如有暗色模式） - AB测试或灰度发布时，确保不同用户看到的HTML版本与对应JS逻辑一致，否则骨架屏可能提前消失而样式未就位
哪些CSS绝对不该内联
不是所有“看起来在首屏”的样式都适合内联。内联收益被抵消甚至反转的情况很常见。
立即学习“前端免费学习笔记（深入）”；
- HTTP/2 环境下且已开启服务器推送（
Link: </styles.css>; rel=preload），内联基本无收益 - 首屏高度动态：如新闻页轮播图、实时股价组件，关键CSS无法静态预判，每次构建都可能漏规则
- 含大量字体声明（
@font-face）、未使用动画（@keyframes）或全局重置（* { box-sizing: border-box }）——它们不参与首屏绘制却增大HTML体积 - 全量
main.css或压缩后仍 >10KB 的样式块，移动端弱网下会拖慢HTML解析，得不偿失
真正值得投入的，是营销页、产品介绍页这类静态为主、转化路径短、SEO要求高的页面；其他场景优先优化 TTFB 和资源压缩更实在。
