最可控稳定的方式是直接提取并内联首屏所需SCSS编译产物；需用@use/@forward显式隔离关键样式层，手动拆分_base.scss、_hero.scss等模块，禁用@forward透传，避免自动提取工具因JS渲染时机、动态样式或Shadow DOM导致漏提。
直接提取并内联首屏所需 SCSS 编译产物，是目前最可控、最稳定的方式。自动化工具（如 Critical、Penthouse）在现代构建链路中容易因 JS 渲染时机、动态样式注入或 Shadow DOM 导致漏提；而 SCSS 层面主动拆分 + 手动标记，能精准锁定 @import 树中真正参与首屏渲染的模块。
如何用 SCSS 的 @use 和 @forward 显式隔离关键样式层
关键 CSS 不是“压缩后的全部 CSS”，而是“首屏 DOM 结构所依赖的最小样式子集”。SCSS 的模块系统恰好支持这种逻辑切分：
- 在
styles/critical/_base.scss中只放重置、根变量、字体加载、html/body基础尺寸等无条件执行的规则 - 在
styles/critical/_hero.scss中仅定义首屏可见区块（如.hero-banner、.primary-cta）及其直接子元素的样式，禁止@import任何非 critical 子模块 - 主入口
critical.scss用@use显式导入上述文件，不走全局@import链 —— 这样 Webpack/Vite 构建时可单独打包该文件，避免混入 footer、sidebar 等非首屏样式 - 禁用
@forward "variables"类型的透传，所有变量必须显式@use "variables" as *或命名空间调用，防止隐式依赖扩散
为什么不能依赖 Autoprefixer + critical CLI 自动提取
自动提取工具在 SCSS 项目中常失效，不是因为工具弱，而是它无法理解预处理器的语义边界：
-
critical基于 HTML 快照分析，但若首屏组件含v-if/ngIf/ 动态 class 绑定，快照可能不含真实 DOM 结构 - SCSS 中
@mixin responsive($breakpoint)编译后生成多套媒体查询，但自动提取器通常只保留默认断点下的规则，导致移动端首屏布局错乱 - 使用
content: attr(data-label)或伪元素生成内容时，提取器无法识别这些样式是否影响首屏视觉，容易误删 - Dart Sass 6.0+ 启用
--no-source-map时，行号映射丢失，penthouse无法准确定位关键规则来源，回退到全量提取
怎样安全地将 SCSS 关键块内联进 HTML
内联本身简单，但路径、缓存、更新一致性才是坑点：
立即学习“前端免费学习笔记（深入）”；
- 不要用构建后
fs.readFileSync('critical.css')拼接 —— Vite/HMR 下热更新时文件未落盘，读取为空 - 推荐在构建时通过插件（如
vite-plugin-sass-dual或自定义 Rollup 插件）监听critical.scss变更，触发重新编译并写入内存中的critical.css字符串供模板注入 - 内联前必须执行
postcss处理：至少包含autoprefixer（补全-webkit-transform等移动端必需前缀）和cssnano（移除注释、合并重复声明），否则 iOS Safari 可能忽略部分规则 - 避免在
内多次内联 —— 即使是同一份 CSS，重复插入会触发浏览器样式重计算；应确保只有一个<style id="critical"></style>节点，并在 JS 加载后用document.getElementById('critical').remove()清理
最关键的细节往往藏在编译链路里：Dart Sass 默认不展开嵌套选择器，而某些 Critical 提取器依赖扁平化结构做匹配；如果你用了 @layer 或原生嵌套语法（& .item），务必确认构建工具已启用 style: 'expanded' 输出模式，否则提取结果会漏掉深层嵌套规则。
