BEM命名本身不影响CSS体积、解析或渲染性能；类名长度经gzip压缩后增幅通常低于0.5%，真正影响性能的是嵌套选择器、未优化的重排重绘及CSS加载顺序。
不会。BEM命名本身对CSS文件体积、HTTP请求数、解析速度、渲染流水线均无实质影响。
类名长度和gzip压缩几乎无关
BEM类名确实更长（如user-profile__avatar--rounded），但现代打包工具默认启用gzip或brotli，重复字符串（__、--、常见前缀）会被高效压缩。实测10万行BEM类名CSS，gzip后体积增幅通常低于0.5%，可忽略。
- 真正影响加载的是CSS总大小、是否拆包、是否内联关键样式，不是类名写法
- 用
grep -oE "[a-zA-Z0-9_-]{20,}" dist/*.css | wc -l能快速确认是否存在异常超长类名（应为0） - 过长类名（>40字符）只在IE11及更老浏览器有选择器截断风险，非性能问题
真正拖慢加载的，是BEM“伪实现”
很多人以为用了BEM就安全了，结果构建产物里全是.card .card__title这类选择器——这不叫BEM，这是用BEM名字包装的嵌套写法，它会显著增加CSS解析开销，且无法被浏览器哈希表快速匹配。
- 检查最终dist目录CSS：
grep -r "\.[a-z]\+ \.[a-z]" dist/，命中即表示存在退化选择器 - Sass中写
.card { &__title { } }是安全的；但.card { & .card__subtitle { } }会编译出空格选择器 - Webpack项目需确认
css-loader未启用exportOnlyLocals: false，否则局部样式可能泄漏成全局嵌套
移动端列表滚动卡顿？和BEM无关
如果VirtualList滚动掉帧，问题一定不在item-list__item这个名字上，而在：
- 每个
<li class="item-list__item">是否真的只挂一个BEM类（禁止叠加list-item等非BEM类） - CSS规则里有没有
width: 100%、flex-wrap: wrap、margin在:hover里触发重排 - 是否误用
.item-list__item:hover，而没用JS切换.item-list--hovered .item-list__item
浏览器不因类名含__多算一次layout，只因你改了height或display才重排。
立即学习“前端免费学习笔记（深入）”；
最容易被忽略的点：BEM不解决CSS引入顺序问题。两个修饰符.card__title--large和.card__title--small冲突，不是命名错了，而是它们所在的CSS文件加载顺序或层叠权重没管住——BEM只管名字，不管谁覆盖谁。
