内联关键CSS生效的前提是浏览器能立即解析并应用，需避开document.write()阻塞、JS空DOM渲染、未处理的外部样式表阻塞；体积须≤1KB以防TCP额外RTT，且禁用@import/url()/@font-face；纯CSR等场景易误判，唯一验证方式是离线模式下首屏元素正常显示。
因为移动端首屏渲染对延迟极度敏感，内联小体积 CSS 能绕过 HTTP 请求、避免渲染阻塞，但前提是它真被浏览器立刻解析并应用——否则反而拖慢页面。
内联 CSS 在移动端生效的前提条件
内联不是“写进 <style> 就完事”。以下任一情况都会让内联失效或变负优化：
-
document.write()或同步脚本放在<head>中，直接中断 HTML parser，<style>根本没机会解析 - 首屏 DOM 完全由 JS 渲染（比如只有空的
<div id="app"></div>），CSS 再快也没内容可画 - 页面里还存在未加
media="print"或未用onload切换的<link rel="stylesheet">，浏览器仍视其为阻塞资源，和内联 CSS 并行排队
为什么体积必须控制在 1KB 以内
关键限制来自 TCP 初始拥塞窗口（通常约 14.6KB 压缩后大小）。但注意：这是指整个 HTML 响应体，不是单看 CSS 字节数。
- 内联 CSS 是 HTML 的一部分，体积过大 → 单次 TCP 包无法装下 → 需要额外 RTT 才能收全 → 首屏渲染延迟反增
- 移动端弱网下 RTT 波动大，1KB 是实测较稳妥的阈值；超过 2KB 就明显增加白屏风险
- 内联内容里含
@import、url()（如背景图）、未处理的@font-face，这些仍会发起新请求并阻塞整条规则应用
哪些场景下内联反而有害
工具提取或人工内联时，容易忽略上下文依赖：
立即学习“前端免费学习笔记（深入）”；
- 纯 CSR（客户端渲染）项目：首屏 DOM 是空的，
critical工具提取结果基本为空或严重误判 - 使用了动态媒体查询（如
@media (max-width: 768px) and (orientation: landscape)），但提取时只跑桌面 UA，漏掉真实首屏匹配规则 - JS 动态添加 class（如
is-loaded、active），而内联 CSS 没覆盖这些状态样式，导致首屏视觉错乱
真正起作用的不是“有没有内联”，而是“内联的内容是否匹配真实首屏渲染路径、是否被浏览器无阻塞地解析并应用”。验证方式只有一种：DevTools Network 面板勾选 Offline 后刷新，看首屏文字/按钮/色块是否仍正常显示。其他全是假设。
