1. 从类名那个“可重复”开始说起
每个写过CSS的人，第一天接触的就是选择器。而class选择器，恐怕是日常开发里用得最多、最顺手的一个。标题里“可重复”这三个字，正是它的灵魂所在——一个class可以挂在任意多个元素上，同样一组样式就能被多个地方共用。这件事听起来简单，但真正用好了，能大幅减少重复代码，也能让样式结构清晰地反映出页面的组件划分。
这篇文章不打算从入门教程那种“选择器是什么”开始讲，而是直接围绕class选择器的“可重复”特性展开：它的语法、它能组合出哪些常用写法、它在实际项目里怎么用才不踩坑，以及我在几个真实项目里遇到的问题和解决过程。无论你是刚入行的新手，还是写了一段时间但总觉得命名混乱、改样式总改出别处的老手，这篇内容都能提供一些可以直接上手的思路。
注意：本文假设你已经了解CSS的基本规则，知道选择器是什么。如果不熟悉class和ID的区别，第2节会专门说明。
2. class选择器的核心机制与可重复性的威力
2.1 class与ID的本质差异
先看一个最基础的问题：class和ID到底差在哪？
- ID在一个页面里只能出现一次，是元素的唯一标识。
- class没有数量限制，相同的class可以出现在任意多个元素上。
这个差异决定了它们的分工。ID适合用来定位“一次性的、与页面结构唯一相关”的东西，比如侧边栏、顶部导航的某个主要容器。而class更适合表达“一类东西的样式”，像按钮、卡片、标签、输入框这类会在页面里多次出现的UI元素，用class是天然正确的选择。
如果非要用ID去写可复用样式，就会出现一个尴尬局面：写第二处的时候必须换个ID，然后为了保持样式一致，又得复制一遍CSS规则，或者在HTML里同时挂多个class。代码数量上去了，维护负担也上去了。而class的“可重复”让样式定义一次、处处生效，这才符合“组件化”的前端开发直觉。
2.2 一个class对应多重元素
.card { border: 1px solid #e0e0e0; border-radius: 8px; padding: 16px; background: #fff; }这一条规则写出来，页面上所有挂载了class="card"的卡片容器都会获得相同的外观。即便页面里有十个卡片，HTML里每个卡片都写一次class="card"，CSS里也只需要这一份规则。这种做法让“样式源”唯一化：将来要调整卡片的圆角，只改CSS定义一处，所有卡片同时更新。
在实际项目里，这个“一处定义、全处生效”的能力极大降低了样式维护成本。我见过不少项目由于早期用了大量ID写样式，后来需求变更要统一调整卡片间距，结果在样式表里挨个找ID改，漏改一两个就造成页面风格不一致。换成class之后，类似问题基本杜绝。
2.3 可重复背后的样式复用架构
“可重复”不仅是节省代码量的技巧，它还推动了一种思维方式的转变：把页面拆解为多个可复用的视觉模块。当你在写结构时习惯性地问自己“这个元素未来会不会复用”“这个样式是否和结构强相关”，命名和规划自然就会往组件化的方向靠。
举个例子：页面里一组商品信息卡片和一组文章摘要卡片，视觉风格相近但内容不同。如果用class描述样式差异，可以这样规划：
<div class="card product-card"> <!-- 商品信息 --> </div> <div class="card article-card"> <!-- 文章摘要 --> </div>这里的card负责基础外观，product-card、article-card负责各自领域的差异化样式。基础样式和扩展样式分离，复用性更强，修改基础样式也不会影响差异化样式。
3. class选择器的常用复合写法
3.1 多class组合与选择器连写
一个元素可以同时挂多个class，这是“可重复”机制在单个元素上的延伸。
<button class="btn btn-primary">确定</button> <button class="btn btn-danger">删除</button>.btn { padding: 8px 16px; border: none; border-radius: 4px; cursor: pointer; } .btn-primary { background: #3370ff; color: #fff; } .btn-danger { background: #e5484d; color: #fff; }这里的两个按钮都共享.btn的基础样式，再通过额外的class各自定义颜色。如果哪天想统一调整所有按钮的圆角，只改.btn一处就行。把“公共部分”下沉到一个通用class里，再把“差异部分”拆到独立class里，这种模式几乎适用于所有多次出现的组件类型。
还有一个常见写法是选择器连写，不表示“一个元素带多个class”，而是表示“元素同时具备这些class才命中样式”：
.btn.btn-primary { font-weight: 600; }这条规则只在元素同时拥有btn和btn-primary两个class时才生效。单独有btn或单独有btn-primary都不会命中。这种写法用于表达“在基础按钮之上，且是主要按钮时，追加一点样式”，语义比直接写在.btn-primary里更精确。但要注意，连写会提高优先级算分，后面第5节会细说。
3.2 后代选择器与子选择器里的class
class选择器最常用的战场，是在层级结构里配合后代选择器使用。
.list-item .price { color: #e5484d; font-weight: 600; } .nav .item { margin: 0 8px; }后代选择器（空格）表示“任意层级的后代”，子选择器（>`）表示“直接的子元素”。在class命名规整的前提下，这两种写法能很自然地表达出“某个模块的内部结构”。
我个人的习惯是：尽量让选择器保持在两到三层以内，像.page-main .sidebar .title .link这种五层嵌套的写法，不仅阅读困难，而且一旦HTML结构微调，样式就可能断掉。与其依赖深层选择器，不如直接在目标元素上定义清晰的class。
/* 不推荐 */ .content .wrapper .card .title span { font-size: 14px; } /* 推荐 */ .title-text { font-size: 14px; }后一种写法的好处很直白：不需要关心父级结构，也不容易因为结构变动而样式失效。代价是HTML里需要多写一个class，但换来的是样式的稳定性和可读性。
3.3 属性选择器结合class使用
class本身也支持属性选择器的语法，最常见的是“包含”匹配：
[class*="btn-"] { font-family: inherit; }这条规则会命中所有class属性里包含btn-字符串的元素。在设计系统里，如果所有按钮类class都以btn-开头，这种写法可以一网打尽地设置公共样式。但它在实际项目里需要克制使用，因为*=是模糊匹配，很容易误伤。比如一个class叫edit-btn-container的元素也会被命中，而你未必有这个意图。
如果确实想用前缀匹配，更精确的是|=匹配，但它要求作用在带连字符的class上才能正确生效，实用度反而不高。实际项目里，我多数时候还是会把公共样式放在.btn这类基础class中，属性选择器更多用于调试或一次性统查场景。
3.4 伪类选择器与class组合
class配合伪类是日常开发里绕不开的组合，比如状态样式：
.btn-primary:hover { background: #2f5ccc; } .btn-primary:disabled { opacity: 0.5; cursor: not-allowed; } .list-item:not(.active) { opacity: 0.7; }这里:not(.active)表示“不带有active这个class时应用样式”，是很有用的一个组合。比如一个列表里当前项高亮、非当前项降低透明度，就可以用这种写法，省去在HTML里给非激活项额外挂class的麻烦。:not()在数值上还支持多个参数，配合class可以写出非常精炼的状态逻辑。
4. class命名规范与常用设计思路
4.1 语义化命名不等于写作文
一个让我印象很深的改进案例是：早期项目里我把一个商品卡片的class写成product-box，后来发现这个结构里还包含了标签、图片和描述，box这个词完全无法表达内容。改成product-card之后，不仅自己看代码舒服，别人接手时也知道这个class对应的是一个完整卡片组件。
但语义化不等于写长句子。一些人会把product-card-title-wrapper这种名字写得越长越好，结果class成为了阅读负担。更好的做法是：短、明确、贴合结构。一个元素在不同场景里允许有不同层级的class，短名字用于基础样式，略长的名字用于特定模块的修饰，这样比一个超长名字既好读又好维护。
4.2 常见class命名惯例
在团队项目里，我通常建议遵循以下惯例：
| 用途 | 建议命名 | 示例 |
|---|---|---|
| 基础组件 | 短名词 | .btn.card.input |
| 状态修饰 | 前缀is-/has- | .is-active.is-disabled |
| 布局结构 | 结构名 | .container.header.sidebar |
| 模块化组件 | 带前缀 | .product-card.user-avatar |
| 工具类 | 短且动词化 | .hidden.clearfix.ellipsis |
这里的核心思路是“一看就知道这个class干什么用”，而不是“一看就知道长什么样”。比如.red这种以颜色定义的class，如果后续UI调整把红色改成了蓝色，class名就需要跟着改动，否则语义和样式就分家了。类似地，.font-large改成.text-xl这类规模词，也比颜色词更抗变化。
4.3 class命名冲突与模块化
当项目页面多、组件多之后，class重名问题几乎一定会出现。一个组件在A页面里叫.item，到了B页面里也正好需要一个样式不同的.item，这时候如果你还用全局按class名定义样式，就很容易出现互相覆盖。
模块化的思路是给每个模块或组件加上命名空间。
.news-item .title { font-size: 16px; } .product-item .title { font-size: 14px; }这样的写法要求class名不冲突且上下文清晰。另一个思路是项目里引入CSS Modules的概念，让构建工具自动生成唯一化的class名，从根本上消除重名问题。如果你在带构建的前端项目里工作，我非常建议关注这个方案，它在解决冲突的同时还保持了类名的可读性。
4.4 类名与设计系统的对应
设计系统里的规范名称，其实可以和class命名直接对应。比如设计稿里叫“主按钮”“危险按钮”，代码里就是.btn-primary.btn-danger。这样做的好处是，设计师和开发者沟通时说的名字与代码里的class名能对得上，减少“设计稿上叫这个名字，代码里叫另一个名字”的认知摩擦。
同时，这也让“可重复”有了更高一层的含义：不仅是样式复用，更是词汇表复用。团队里的命名词汇统一之后，新页面开发时直接拿已有class来组合，不需要再造一套新词，代码质量和沟通效率都明显更好。
5. 优先级、层叠与class的实战博弈
5.1 优先级计算与class的位置
CSS的优先级，很多人知道“ID > class > 标签”，但真正在项目里踩坑之后才会重视它。class在所有选择器中的优先级是“一个class一分”，多个class连写就是更高分。比如.card .title这个后代选择器，包含两个class，优先级高于单独一个.title。这正是一些“明明写了样式却盖不过别人”的场景背后的原因。
来看个具体例子：
.card .title { color: #333; } .title { color: #999; }同一个元素如果同时被这两条规则命中，最终生效的是上面的.card .title，因为它的优先级（两个class）比.title（一个class）更高。很多人写样式时忽略了这一点，只在被覆盖之后才发现需要增加选择器的层级或者加!important。而正确做法是先看一眼是“同优先级后写覆盖前写”，还是“低优先级想覆盖高优先级”，再决定怎么调整。
为了让样式更容易维护，团队实践中常约定一个“优先级上限”：如果不是特殊情况，单条规则的选择器不超过两个class。超过了，就该考虑重构class命名或组织结构，而不是继续叠加嵌套。
5.2 class与样式分离的思想
“可重复”有一个隐含前提：class只负责表达“样式类别”，而不是“具体某个元素”。如果你在HTML里写class="active"，JS里也用它来切状态，那这个class就是一个“样式和状态双用途”的类。这种情况可以工作，但容易出现样式与逻辑耦合的问题。
比如JS里需要根据状态给元素动态添加class时，更推荐用“工具类”或“状态类”来操作，而保持基础的视觉类不变：
element.classList.add('is-active'); element.classList.remove('is-active');这样，CSS里可以用.is-active来表达激活态的样式，JS只负责状态切换，两者解耦。哪怕将来不再用class切换状态，改成了><div class="post-card"> <div class="post-card-cover"> <img src="cover.jpg" alt="封面图"> </div> <div class="post-card-body"> <h3 class="post-card-title">这里是一篇文章的标题</h3> <p class="post-card-excerpt">这里是文章的摘要文字…</p> <div class="post-card-meta"> <span class="tag">前端</span> <span class="tag tag-highlight">热门</span> <span class="meta-read">1280 阅读</span> </div> </div> </div>
CSS的规划思路：
.post-card { border: 1px solid #eee; border-radius: 12px; overflow: hidden; transition: box-shadow 0.2s ease; } .post-card:hover { box-shadow: 0 6px 16px rgba(0, 0, 0, 0.08); } .post-card-body { padding: 16px; } .post-card-title { font-size: 18px; font-weight: 600; line-height: 1.4; } .post-card-excerpt { font-size: 14px; color: #666; margin: 8px 0 12px; } .post-card-meta { display: flex; align-items: center; } .tag { display: inline-block; padding: 2px 8px; border-radius: 4px; font-size: 12px; background: #f2f3f5; color: #555; } .tag-highlight { background: #fff3e0; color: #e65100; } .meta-read { margin-left: auto; font-size: 12px; color: #999; }这里的命名规律是：以post-card为前缀，内部的标题、摘要、元信息都带前缀。这样写的好处是：即便页面里还有其他模块叫title或meta，也不会与这个卡片的类冲突；而且看HTML的时候，所有与卡片相关的类都能一眼识别。
标签里的tag和tag-highlight，正好用上了多class组合的思路：tag负责基础标签样式，tag-highlight负责高亮变体。将来如果想增加一个tag-secondary，只需要新增一个独立类，不影响tag的基础样式。
6.2 样式复用与结构调整
假设后来产品要求“文章摘要可选是否显示”，也就是有些卡片隐藏摘要。如果是传统写法，可能需要给卡片增加一个“隐藏摘要”的类，然后在CSS里写：
.post-card.no-excerpt .post-card-excerpt { display: none; }这种写法可行，但把“摘要是否显示”这个状态与卡片组件耦合在了一起。如果多个组件都有类似需求，更好的做法是定义一个通用工具类：
.hidden { display: none !important; }然后在需要隐藏摘要的卡片里，直接给post-card-excerpt加上hidden类。工具类的“可重复”价值就在这里体现：它不关心元素是什么，只负责提供一种通用能力。当然，前面说过!important要谨慎使用，像hidden这种工具类为了确保在任何优先级下都能隐藏元素，适当地使用!important其实是常见做法，这样可以把“隐藏”这个动作做得绝对可靠。
6.3 类名是否该区分大小写
class名在HTML里是区分大小写的，但实际浏览器处理时多数会视作一致，不过为了规范和安全，建议统一使用小写字母加连字符的命名风格。比如使用post-card而不是postCard或PostCard。这不仅是样式书写的习惯，也因为很多团队工具链会基于命名推断文件关系，统一风格有利于自动化处理的可靠性。
6.4 预留可扩展的命名空间
在项目迭代中，需求变更非常频繁。一个卡片模块可能从普通样式演变成带主图、带视频、带活动标识等多种变体。如果命名从一开始就带有“模块前缀 + 语义子项”的结构化特点，扩展新变体时只需增加一个新的修饰类，而不用大规模改动已有样式。比如活动卡片可以写成：
<div class="post-card post-card-promo"> ... </div>.post-card-promo只在有特殊活动样式时添加，它叠加在post-card之上。这种“基础类加修饰类”的组合在真实项目中非常常用，也是“可重复”在复杂场景下的进阶玩法。
7. 常见问题与踩坑记录
7.1 class被覆盖但又找不到源头
这个问题的典型场景是：我明明定义了.footer .link的颜色，但页面上看到的却是另一个颜色。排查步骤一般是这样：
- 打开浏览器开发者工具，选中目标元素。
- 查看Styles面板里哪些规则被划掉了，哪些规则生效。
- 对比划掉规则的优先级和来源，特别关注是否有更高层级的选择器命中。
- 检查是否来自第三方库或浏览器默认样式。
大多数“找不到源头”的情况，是有人先你一步写了一条更高优先级的选择器，或者用了!important。此时不要着急增加优先级硬碰硬，而是思考是否可以重构class结构来避免长期对抗。
7.2 多class和条件class的最佳实践
动态class是JS和CSS打交道最频繁的地方。不同框架里写法不同，但核心都是通过条件判断把某些class加到元素上。
// 原始写法 const className = 'btn' + (active ? ' is-active' : '');.btn.is-active { border-color: #3370ff; box-shadow: 0 0 0 2px rgba(51, 112, 255, 0.2); }这样切状态时只操作is-active这一个类，基础类btn保持不变。比起把整个class替换掉，这种方式在状态切换和样式维护上都更稳定。我实践中遇到过一个老项目把激活态直接替换成另一个完整类名，结果每次切换都要同时改多个地方，后来统一改成“基础类+状态类”的组合模式，维护成本大幅下降。
7.3 class太多会不会有性能问题
这是个被反复问起的问题：一个元素上挂很多class，或者全局class定义很多，会不会影响性能。
现代浏览器对CSS选择器的匹配优化已经做得非常好，class选择器的匹配速度也很快。真正影响渲染性能的往往是别的原因，比如过深的后代选择器、复杂的伪类组合、极长的属性选择器，以及滥用通用匹配符。class选择器本身不是性能瓶颈。为了极端的“性能”而不使用class，反而会因为样式分散让代码更难维护，那就不值当了。
有一种值得注意的场景：动态往元素上添加和删除class，会触发样式重算。频繁在动画循环里修改class，确实可能造成性能压力。但这种情况更合适的做法是让动画脱离主线程，或者在布局稳定的属性上做变换，而不是从源头上减少class的定义。
7.4 与CSS变量联动的class设计
CSS变量（自定义属性）与class结合，是近年很实用的做法。你可以在class里定义局部变量，再在子元素中引用：
.card { --card-padding: 16px; --card-radius: 8px; } .card-compact { --card-padding: 12px; --card-radius: 4px; } .card-body { padding: var(--card-padding); border-radius: var(--card-radius); }这样做的好处是，当切换卡片变体时，内部结构不需要额外写规则，只需要变量被覆盖，所有引用变量的子元素样式自动变化。class的“可重复”与CSS变量的“可覆盖”结合，让组件变体控制变得非常优雅。我在实际项目里用这套方式做过按钮、卡片、弹窗等多种组件的尺寸变体，效果都很理想。
8. 我在实战中养成的class选择器使用习惯
写到这里，分享几个我自己多年来总结的习惯，算不上金科玉律，但确实帮我节省了不少排障时间。
第一个习惯：写HTML之前先想class命名。很多人写结构时随手起名，写完才发现样式没法规整组织。我现在一般先在草稿里列清楚这个模块会有哪些子元素，它们之间的关系是什么，再落笔写class。这样虽然前期多花了一两分钟，但后面写CSS和改版时，思路会清晰很多。
第二个习惯：尽量不写超过三层的后代选择器。如果确实有三层关系，我会反过来检查是不是HTML结构太深了，能不能把目标元素改成更扁平的class结构。实际项目中，扁平化结构往往比依赖层级选择器的代码更健壮。
第三个习惯：善用:not()和状态类，减少不必要的class复制。比如一个列表需要高亮其中一项，用.list-item:not(.is-active)来给非激活项降透明度，就比在HTML里给每个非激活项加一个.dimmed类省事得多。
第四个习惯：class命名词汇保持统一。团队协作时，btn、button这两种叫法其实很常见，但如果不统一，代码里会出现.btn-primary和.button-danger这样的混搭，看着就头疼。我建议在团队里维护一份简短的class命名约定，不一定要覆盖所有场景，只要把最高频的几十个词约定好，新成员上手就能快速产出风格一致的代码。
css选择器的路没有尽头，class作为最基础也最灵活的一环，值得每个前端反复琢磨。如果你在项目里也有过因为class命名不规范而反复返工的经历，不妨从今天开始，试着为你的下一个页面制定一套清晰的class命名规则，再配合“基础类加修饰类”的组合方式，实际体验一下“可重复”带来的爽快感。
