类名应按功能或语义命名而非样式效果,如用 search-submit 而非 btn-primary;避免颜色、尺寸等视觉属性;采用 BEM 风格并约定前缀;选择器宜浅层、单类名优先;禁用 ID 和标签选择器;用自定义属性管理状态。

类名命名要能表达组件意图,而不是样式效果
用 btn-primary 这类带样式含义的类名,一旦设计改了蓝色变紫色,类名就失效或误导;更糟的是,它无法跨项目复用。应该按功能或语义来命,比如 search-submit、user-avatar、card-header —— 它们描述“这是什么”,而不是“它长什么样”。
实际操作建议:
- 避免在类名中出现颜色(
red-text)、尺寸(large-btn)、位置(left-sidebar)等视觉属性 - 采用 BEM 风格时,确保
block名体现组件边界,如product-card而非card,防止全局冲突 - 团队需约定前缀规则,比如内部系统统一用
app-,第三方嵌入组件用ext-
结构层级越浅、选择器越稳定
写 .sidebar .nav .item a:hover 这种深度选择器,只要 DOM 微调(比如加个 <div> 包裹),样式就断。深层嵌套也放大了 CSS 特异性,后续覆盖成本高。
<p>优化方向:</p>
<ul>
<li>优先用单层类名直接控制元素,如给链接加 <code>nav-link,而非依赖父级结构推导
:is() 或 :where() 合并同类选择器,减少重复声明,例如 :is(.btn, .link).is-active
[data-md] code 比 article pre code 更耐改避免 ID 和标签选择器用于样式控制
#header 看似明确,但 ID 在页面中必须唯一,导致组件无法复用;h1、ul 这类标签选择器则把样式和 HTML 语义强绑,换用 div role="heading" 就失效。
真实影响:
- ID 选择器特异性过高(100),常逼迫后续用
!important或更深选择器覆盖,形成恶性循环 - 标签选择器缺乏语义隔离,一个
ul { margin: 0 }可能意外清掉导航菜单外边距 - 改用类名后,可通过
class="list-unstyled"显式控制,意图清晰且可组合
用自定义属性辅助状态管理,减少动态类名爆炸
为每个交互状态(hover / active / disabled / loading)都写一个类,很快会冒出 btn-disabled-loading、btn-hover-active 这类组合类,维护成本陡增。
更可持续的做法:
- 用
data-state或data-loading等自定义属性标记状态,CSS 写成[data-loading] { opacity: 0.6; pointer-events: none; } - JS 控制状态只需改属性值,不操作 classList,避免 class 增删逻辑错乱
- 搭配
:has()可实现父子联动,比如.card:has([data-error]) { border-color: #f00; },无需额外加 error 类到 card 上


















