class 命名不只是代码，更是给队友的“说明书”

相信不少前端开发者都经历过这种崩溃时刻：接手一个三个月前的项目，看着样式表里满屏的 .box、.inner、.container2，完全不知道哪个控制布局，哪个负责交互。更惨的是，改了一个按钮的颜色，结果页面上三个没关系的区块也跟着变了。

这不是 CSS 写得不够好，而是 class 命名规范 在最初就没立稳脚跟。很多人觉得类名只是给浏览器看的，能跑就行，但事实上，它是程序员之间沟通效率最高的载体。好的命名，能让维护成本降低一半。

别用视觉特征做名字

新手最容易犯的错误，就是根据外观来命名。比如把红色的警告框写成 .red-alert，把圆形的头像写成 .circle-avatar。这在初期看似直观，一旦设计稿调整，颜色从红变蓝，形状从圆变方，你就得全量搜索替换类名，风险极大。

正确的思路是描述“功能”和“语义”。那个红色框，本质上是一个 .warning-box；圆形头像的核心身份是 .user-avatar。无论将来设计如何微调，它的业务含义没变，类名就不需要动。让代码适应业务逻辑，而不是适应像素值。

用连接符暗示层级关系

在项目变大后，样式冲突是家常便饭。为了避免选择器权重打得太高（比如被迫用 !important），我们需要通过命名来体现组件的归属权。

目前业界通用的 小写字母 + 短横线（kebab-case） 风格依然是首选。对于嵌套元素，推荐使用双下划线表示子元素，单下划线表示修饰符（类似 BEM 思想）。例如导航栏下的链接，不应写成 .nav-link，而建议写成 .nav__link。

这样做的好处很明显：一眼就能看出 .nav 是大模块，link 属于它。即使其他文件里也有一个 .link，也不会轻易产生样式污染。清晰的层级结构，能有效降低 CSS 选择器的复杂度。

状态类要与布局类分离

还有一个高频痛点：当组件处于“加载中”、“禁用”或“激活”状态时，怎么修改样式？

很多团队习惯直接改主类名，比如把 .btn 改成 .btn-loading，导致原有的基础样式丢失，或者需要在 CSS 里重复编写大量相同的属性。更优雅的做法是将状态独立出来。

保留核心的 .btn，额外添加状态类如 .is-disabled 或 .has-error。这样主样式始终稳定，状态叠加只负责微调。这种关注点分离的逻辑，能让你的代码在复杂交互场景下依然保持干净。

统一规范比技术选型更重要

讨论具体是用 BEM、SMACSS 还是原子化 CSS 之前，团队内部必须先达成一致。有时候，一个简单的约定胜过复杂的理论。比如规定：

• 全局通用组件不加前缀（如 .input）；
• 业务特定组件加业务前缀（如 .user-card）；
• 禁止使用缩写（除非是行业共识，如 img、id）。

这些规则不需要写在文档里供人传阅，而是要嵌入到代码审查和开发工具中。借助 ESLint 插件强制检查类名格式，比口头强调有效得多。

结语

代码最终是人读的，机器只是执行者。当你花十分钟纠结一个类名叫 .wrapper-mod 还是 .layout-wrap 时，看似耽误了进度，实则是为未来节省了大量排查时间。

好的命名习惯，是对自己未来的投资，也是给队友的一份体面。下次动手写标签前，多问一句：如果半年后的人看到这个名字，能立刻明白它的作用吗？如果答案是肯定的，那这就是一段高质量代码的开始。