类名长度本身对渲染性能几乎无影响，真正拖慢页面的是选择器嵌套深度和匹配逻辑；浏览器通过哈希表查找类名是o(1)时间复杂度，而深层嵌套选择器（如.a .b .c）需从右向左回溯匹配，导致recalculate style耗时飙升。
不会。类名长度本身对渲染性能几乎没影响，真正拖慢页面的是选择器的嵌套深度和匹配逻辑，不是字符数。
浏览器查类名其实很快
Chrome、Safari 等现代引擎会把所有类名存进哈希表（m_classRules），查找是 O(1) 时间复杂度。哪怕你写 .flying-in-the-sky-pig--with-umbrella，解析时多循环几个字符、算一次稍长的哈希值，耗时也远低于 0.01ms——这在实际渲染中完全不可测。
- 真正花时间的是「匹配过程」：比如
.a .b .c .d .e要从右往左逐层回溯父节点 - 类名长只让 HTML 和 CSS 文件体积略大，影响的是网络传输和内存占用，不是样式计算
- 打包工具（如 esbuild、Vite）会自动压缩类名（尤其配合 CSS Modules 或 scoped），原始长度更无关紧要
为什么有人觉得“名字长=慢”
混淆了两个问题：命名长度 vs 选择器结构复杂度。真实项目里，长名字往往伴随深层嵌套（比如 .user-profile-card .user-profile-card__header .user-profile-card__header__title），这时慢的不是 user-profile-card__header__title 这个字符串，而是前面那串祖先链。
- 错误写法：
.card .card__title—— 多一层匹配，DOM 节点越多，开销越明显 - 正确写法：
.card__title—— 单类名，直接命中哈希表，无回溯 - BEM 名字长，但换来的是扁平选择器结构；OOCSS 名字短，却可能靠
.media .img这种组合撑起逻辑
该警惕的其实是这三类“伪性能陷阱”
比起删减类名字符，优先处理这些真瓶颈：
-
*[class^="icon-"]：通配符 + 属性前缀，在低端 Android WebView 里可能阻塞样式解析 -
.list-item:not(.disabled)：否定伪类无法被索引，每帧都得遍历检查状态 -
button:hover或[data-loading]：触摸设备上虽降级，但仍触发重算，改用.button--loading更稳
名字要不要短，取决于可读性和协作成本——.btn--primary 比 .b1 好，不是因为快，而是别人能看懂你在干啥。性能优化真正的发力点，永远在选择器怎么写，而不是怎么缩写。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
