因为默认lessc编译会全量打包@import样式（含非首屏、动画、:hover等），导致内联后体积膨胀、CSSOM构建延迟；应改用@import (reference)隔离变量混入，建独立critical.less入口显式引入首屏规则，并通过Coverage验证使用率≥95%。
为什么直接用 lessc 编译出的 CSS 不适合首屏内联
因为默认编译会把所有 @import 的样式（包括非首屏组件、动画、:hover 规则）一股脑打包进一个文件，导致内联后体积膨胀、关键路径变长。浏览器解析大块 <style></style> 仍要花时间构建 CSSOM，起不到“急用包”效果。
用 @import (reference) 隔离变量与混入，不输出样式代码
这是 Less 控制样式输出时机的核心机制。只有显式调用的 .mixin 或直接写的规则才会生成 CSS；@import (reference) 只导入变量和混入定义，不产生任何选择器。
- 在
_variables.less和_mixins.less开头加@import (reference)声明，确保它们被其他模块引用时不带副作用 - 首屏样式入口（如
critical.less）只@import (reference)公共变量/混入，再手动写或调用真正需要的规则 - 避免在
_variables.less里写@font-face或@keyframes—— 它们会被每个引用该文件的入口重复输出
按功能域拆分 Less 入口，单独提取 critical.css
Webpack/Vite 构建时，不能靠正则或人工复制来筛首屏样式。必须让构建流程“知道”哪些 Less 是专为关键路径服务的。
- 新建
styles/critical.less，只@import (reference)变量和混入，再显式引入首屏组件样式（如@import './components/header.less';） - Webpack 中用
mini-css-extract-plugin单独处理这个入口：entry: { critical: './styles/critical.less' } - Vite 用户推荐
vite-plugin-critical-css，它会在 SSR 渲染首屏 HTML 后，真实提取 DOM 中用到的选择器，比静态分析更准 - 注意：若用了
.extend()，提取结果会漏掉被扩展的选择器 —— 改用.mixin()显式调用更可控
内联后验证是否真覆盖首屏渲染所需样式
光看 HTML 里有没有 <style data-critters></style> 没用。关键要看浏览器行为是否真的不卡顿。
立即学习“前端免费学习笔记（深入）”；
- Chrome DevTools → Coverage → 刷新页面，确认
critical.css文件中绿色（已使用）字节占比 ≥95% - 禁用缓存后刷新，Network 面板检查
index.html下方是否立刻出现 render-blocking 样式 —— 如果没有，说明关键 CSS 已生效 - 特别留意伪类（如
.btn:hover）和继承链上级（如article p）是否被漏掉：自动化工具不模拟交互和完整 DOM 树，这类规则得手动补进critical.less
Less 本身不决定关键 CSS 是否精准，它只是提供变量隔离和按需编译的能力。真正容易被忽略的是：变量和混入的导入方式（(reference)）、首屏样式的物理边界（独立入口文件）、以及提取后必须用 Coverage + 真实渲染验证 —— 这三步缺一不可。
