内联CSS仅适用于首屏必须立即渲染的极少数关键样式，如html/body基础样式；不适用于含伪类、媒体查询或依赖未注入CSS变量的场景，且HTTP/2/3下基本无需内联。
内联CSS适合哪些场景
只在页面生命周期极短、复用率极低、且无服务端渲染能力的场景下才值得内联。比如单页应用中某个临时弹窗的样式、A/B测试分支里的专属UI、或静态生成时已知绝对不复用的首屏关键样式。不是“能内联就内联”，而是“非内联不可时才内联”。
常见错误现象：style标签里塞了整套normalize.css，或者把组件库的Button、Modal样式全抄进去——这反而拖慢首屏解析，还让缓存彻底失效。
- 适用：首屏必须立即渲染的几行样式（如
html、body背景、字体、最小尺寸） - 不适用：含伪类（
:hover、:focus-within）、媒体查询（@media）较多的样式，或依赖CSS自定义属性（--color-primary）但未同步注入变量的场景 - 注意：服务端渲染（SSR）框架如Next.js、Nuxt默认已做关键CSS提取，手动内联可能重复或冲突
怎么安全地内联CSS而不破坏维护性
核心是“隔离+标记+自动化”。不能靠人肉复制粘贴，否则改一次全局CSS就得翻所有HTML文件找style块。
使用场景：构建流程中已有PostCSS或Webpack，且项目已接入CSS提取插件（如mini-css-extract-plugin或critters）。
立即学习“前端免费学习笔记（深入）”；
- 用
critters自动提取并内联首屏关键CSS，它会真正分析DOM结构，而非简单截取前N行 - 若手写，只内联带
critical注释的区块，例如/* critical */ .header { height: 60px; }，再配合构建脚本提取 - 禁止在
style标签里写@import或@layer——这些在内联上下文中无效，浏览器直接忽略
内联后为什么CSS优先级变乱了
因为内联style标签的层叠顺序，和外部CSS文件加载时机、link位置强相关。浏览器按HTML顺序解析，style标签越靠前，越容易被后面引入的CSS覆盖；但若外部CSS用了!important或更具体的选择器，内联样式照样失效。
性能影响：内联本身不增加请求数，但会增大HTML体积。超过约14KB（TCP初始拥塞窗口典型值），可能多一个RTT才能收完首屏HTML，得不偿失。
- 检查是否在
head末尾放了style，却在body开头又引入了main.css——后者实际会覆盖前者 - 避免用
!important硬顶，改用提高选择器特异性，例如把.btn改成body .btn - Chrome DevTools的
Computed面板里看某条样式“来源”列，能清楚看到是来自style标签还是main.css
HTTP/2或HTTP/3下还用内联吗
基本不用。HTTP/2支持多路复用，多个小CSS文件可并行传输，且能被CDN和浏览器长期缓存；HTTP/3进一步降低队头阻塞影响。此时内联的收益趋近于零，反而牺牲缓存复用和压缩率。
容易踩的坑：本地开发启了HTTP/2，但生产环境CDN（如Cloudflare）配置没开HTTP/2，或老版本iOS WebView仍走HTTP/1.1——这时内联与否要按真实终端协议分布决定，不能只看本地测试。
- 查真实协议：打开DevTools →
Network→ 刷新 → 看Protocol列是h2还是http/1.1 - 如果超过70%流量走HTTP/2+，内联收益小于10ms，不如省事用外链
- 唯一例外：HTTP/2已启用，但CSS文件因动态生成（如主题色服务端注入）无法缓存——这时内联反而是更可控的选择
事情说清了就结束。最常被忽略的是：内联不是优化手段，而是权衡结果；你得先确认那几行CSS真正在首屏渲染路径上，而不是凭感觉“这个很重要”。
