oocss是一种面向对象的css架构方法，核心是解耦视觉属性与容器结构、分离行为与位置，通过对象类、修饰类和工具类的组合实现高复用性，而非解决命名问题。
什么是OOCSS，它解决的不是命名焦虑而是复用断层
OOCSS（Object-Oriented CSS）不是教你怎么起名，而是帮你把样式从“某个按钮在首页顶部的蓝色大号状态”里抽出来，变成可拼装的零件。很多人一上来就纠结.btn-primary还是.c-button--large，其实问题不在命名风格，而在是否真把padding、border-radius、font-size这些视觉属性和容器结构解耦了。
典型错误现象：.header-nav-item-active这种类名看着语义清晰，但一旦导航出现在侧边栏或移动端弹层，就得再写一套.sidebar-nav-item-active——本质是把位置（where）和状态（what）混在一起了。
- 真正该拆的是“行为”：比如
.is-disabled应独立于任何组件，加在.btn、.input、.card上都生效 - 结构类（如
.u-clearfix）和皮肤类（如.theme-dark）必须能叠加使用，不能互相覆盖display或position - 避免用
!important强行覆盖——OOCSS的层级靠组合顺序和低特异性维持，加!important等于提前宣告复用失败
怎么写一个真正可复用的.btn对象类
不是写.btn就叫OOCSS，关键看它是否允许你只改类名不改HTML结构就能切换形态。比如<button class="btn btn--secondary btn--small"></button>能直接替代<a class="btn btn--primary"></a>，前提是.btn本身不依赖button标签，也不预设display: inline-block。
常见错误：把.btn写成button.btn { display: inline-block; }——这样.btn就不能用在<div>或<code><span></span>上了。
立即学习“前端免费学习笔记（深入）”；
-
.btn只定义基础交互样式：cursor: pointer、user-select: none、outline: none，不碰padding、background、font-size - 尺寸变体
.btn--small、.btn--large只负责padding和font-size，不重置line-height或height（避免和行内元素冲突） - 颜色变体
.btn--primary只管background-color和color，不带border（边框由.btn--outline这类修饰类控制）
为什么.u-text-center比.text-center更安全
前缀u-（utility）不是为了显得高级，而是明确告诉团队：“这个类只干一件事，且可以加在任何元素上”。没有前缀的.text-center容易被误认为是某个模块的局部样式，后续有人在.card里写.text-center，结果全局.text-center被覆盖或冲突。
性能影响常被忽略：工具类如果用@apply（Tailwind式）或@mixin生成，会导致CSS体积膨胀；而纯类名方式（.u-text-center { text-align: center; }）可被浏览器高效复用，且支持PurgeCSS精准剔除未用类。
- 所有工具类必须原子化：一个类只对应一个CSS声明，禁止
.u-mb-20 { margin-bottom: 20px; line-height: 1.4; } - 响应式工具类如
.u-text-center@sm需确保媒体查询嵌套层级不破坏组合逻辑（例如.btn.u-text-center@sm要能正确生效） - 避免用
!important实现工具类——若需要强制覆盖，说明基础对象类的默认值设计不合理
OOCSS落地时最常被忽略的约束条件
不是写了.o-layout和.c-card就自动OOCSS了。真正的约束在于团队协作中能否守住三条线：对象类不带上下文、工具类不带副作用、修饰类不改变结构流。
最容易踩的坑是“半途而废”：比如写了.o-form，却在其中用label + input相邻选择器控制间距——这会让.o-form无法用在label和input被div隔开的场景，复用性瞬间归零。
- 对象类的css选择器必须是单类名（
.o-card），禁用.o-card h3或.o-card > .o-card__title——子元素样式交给.o-card__title自己管 - 所有修饰类（
--hover、--disabled）必须通过:not()或显式重置保证可叠加，比如.btn--disabled:hover不能意外触发.btn:hover的背景变化 - 构建时必须校验类名前缀一致性：用postcss插件扫描
class="btn u-clearfix"这种混用非前缀类的情况，及时报警
复杂点在于，OOCSS不是写完就一劳永逸的规范，而是持续对抗“快捷路径诱惑”的过程——每次想给某个组件写个.homepage-hero__cta，都要问一句：这个CTA的尺寸、颜色、禁用态，是不是已经能在现有对象+修饰+工具类中拼出来。