SCSS编译本身不导致CPU高占用，瓶颈在于嵌套超4层、@extend滥用及动画属性误用引发浏览器高频重排重绘；需重构深层嵌套、用@at-root提级、改transform替代top/width动画。
SCSS 编译过程本身不会直接导致运行时 CPU 占用高，但编译阶段卡顿、或编译出的 CSS 在浏览器中执行时引发高频重排重绘，才是真实瓶颈。问题不在 sass 命令本身慢，而在于嵌套失控、选择器爆炸、动画属性误用这三类写法，让浏览器渲染线程持续满载。
SCSS 嵌套过深触发浏览器匹配开销飙升
浏览器从右往左解析选择器，.a .b .c .d .title 这类 5 层嵌套，每帧都要回溯验证父级是否存在。DOM 越深、滚动越频繁，CPU 就越忙——这不是编译慢，是运行时在“反复查户口”。
- 4 层是临界点：一旦出现
.page .main .content .card，优先重构，别靠!important硬压 - 避免标签名嵌套（如
ul li a），HTML 结构微调就导致样式失效 - 用
@at-root提级输出工具类，而不是缩进假装有上下文：@at-root .u-text-center { text-align: center; } - 慎用
&在@media内嵌套，它会展开全部父路径，生成不可控长选择器
滥用 @extend 导致 CSS 规则爆炸和重绘失控
@extend 不共享声明，只拼接选择器。一个 %btn-base 被 10 个组件 @extend，最终 CSS 里就出现 10 份重复的 padding: 0.5rem，gzip 后仍冗余；更糟的是，这些规则全在主线程参与 Layout/Paint 计算。
- 禁用跨组件
@extend，改用%placeholder+ CSS 自定义属性组合：:root { --space-sm: 0.5rem; }，组件内统一用margin: var(--space-sm) -
%placeholder必须声明在顶层，不能嵌套在.card { .title { @extend %heading; } }里，否则 Sass 会拼出.card .card .title这类错误选择器 - 含
:hover、@media或 BEM 子元素（如&__header）的占位符，一律不许定义——它们必然触发冗余输出
CSS 动画属性写错，让主线程每帧强制 Layout
SCSS 本身不执行动画，但你用它生成了 top: 100px 或 width: 200px 的 @keyframes，浏览器就得每帧重排。这类动画在 DevTools Performance 面板里表现为密集的 Layout 条，占比超 30% 就坐实是元凶。
立即学习“前端免费学习笔记（深入）”；
- 把
left: 100px改成transform: translateX(100px)，把height: 50px改成transform: scaleY(0.5) -
will-change: transform必须提前加在初始状态（不是 hover 后才加），否则浏览器来不及升层 - 避免在
position: fixed元素上混用top和transform，合成器可能直接放弃优化 - 禁用
filter: blur()动画——GPU 不加速，CPU 持续满载；改用backdrop-filter（仅限 backdrop 场景）或预渲染图
真正容易被忽略的是：SCSS 编译快不代表页面快。嵌套层级、@extend 使用方式、动画属性选择，这三者共同决定了最终 CSS 在浏览器中如何执行——而执行效率，才是 CPU 占用高的根源。
