BEM通过扁平单类名选择器减少CSS匹配开销，避免后代选择器回溯，提升渲染性能；需严格遵循命名规范、合理使用Sass模块化和PostCSS配置，并以拆分CSS chunk优化体积。
为什么BEM能减少CSS选择器匹配开销
浏览器渲染时，CSS选择器是从右往左匹配的。.header__title--large 这种BEM命名生成的单类名选择器，比 .header .title.large 这类多层嵌套选择器快得多——前者只需查一次class哈希表，后者要回溯父元素、再查多个class、还要判断顺序和层级。
预处理器（如Sass）本身不参与运行时匹配，但BEM结构直接影响它编译出的最终CSS质量。如果Sass里写的是嵌套过深的 &__item { &--active { ... } }，最终输出仍是扁平单类名；可一旦混用后代选择器（比如 .menu &__link:hover），就容易产出 .menu .menu__link:hover 这种带空格的选择器，直接拖慢渲染。
- 避免在BEM块内使用
&嵌套出后代关系，改用修饰符或子元素显式命名：.card__content而非.card &__content - Sass中慎用
@at-root (without: rule)或@at-root (with: rule)，它们可能意外打破BEM扁平性 - 检查编译后CSS：搜索
>、+等组合器，确认是否超出BEM约定范围
Sass编译慢？先查@import和@use的滥用
预处理器编译效率瓶颈往往不在语法本身，而在文件组织。Sass 1.32+ 推荐用 @use 替代 @import，不仅语义清晰，更重要的是：它天然支持模块作用域隔离，避免重复解析同一文件。
常见错误是把所有变量/混合宏塞进一个 _variables.scss，然后在每个组件文件里 @use "variables" ——看似合理，实则每次编译都会重新解析该文件，且无法利用缓存。更糟的是，有人还在 @use 后加 as *，导致命名冲突和隐式全局污染，间接增加符号表查找时间。
立即学习“前端免费学习笔记（深入）”；
- 按功能拆分
@use模块：@use "sass:math"、@use "utils/breakpoints" as bp - 禁止
@use ".../variables" as *；统一用具名导入，比如@use "tokens" as t，再通过t.$spacing-sm访问 - Webpack + sass-loader 场景下，确保
additionalData配置没重复注入全局变量文件
PostCSS插件链如何悄悄拖垮编译速度
很多人以为“用了PostCSS就等于优化了”，其实像 postcss-preset-env、cssnano 这类插件默认开启大量特性检测和转换，尤其在开发阶段，每次保存都触发全量重处理，比Sass编译本身还慢。
典型表现是：修改一行SCSS，终端卡顿3秒以上才看到CSS更新。用 DEBUG=* 查日志会发现 postcss-preset-env 在反复解析 :is()、color-mix() 等尚未广泛支持的语法——而你的项目根本没用这些。
- 开发模式下禁用
cssnano；用postcss-discard-comments替代其压缩逻辑 -
postcss-preset-env显式配置stage: 3和features白名单，关掉nesting-rules（BEM已规避嵌套需求） - 若用Vite，检查
css.postcss.plugins是否重复注册了同个插件两次
BEM类名太长导致CSS体积膨胀？别乱删
有人为“减小CSS体积”把 .o-header__logo--sticky 简化成 .h-l-s，这反而破坏BEM可维护性，且现代Gzip对重复类名压缩率极高——真正影响体积的是未拆分的巨无霸CSS文件，不是类名长度。
更关键的是：短类名易冲突。比如 .btn 和第三方库的 .btn 碰上，就得靠 !important 或更高权重选择器救场，最终产出的CSS反而更大、更难调试。
- 类名长度不是性能瓶颈，无需手动缩写；BEM工具如
scss-bem可自动生成规范命名，不增加认知负担 - 真正该做的是按路由/组件拆分CSS chunk，让首屏只加载必要样式
- 注意
content-visibility: auto对隐藏区块内CSS规则的惰性匹配影响——BEM扁平结构在此场景下优势更明显
最常被忽略的一点：BEM本身不解决选择器性能问题，它只是帮你避开坑。真正起作用的是你有没有坚持“一个元素只有一个BEM类名”、有没有杜绝 div.header > ul > li:first-child a 这种反模式写法——这些细节不会报错，但会在页面变复杂后突然暴露成渲染卡顿。
