OOCSS是一种将CSS拆分为结构、皮肤、容器等职责单一可复用对象的约束思路，区别于绑定HTML位置或内容的命名（如.header-nav），强调类名中性、组合使用、解耦表现与结构。
什么是OOCSS，它和普通CSS命名有啥实际区别
OOCSS不是新语法，是写CSS时的一套约束思路：把样式拆成可复用的「对象」，而不是为某个HTML结构写死一套类名。比如你写 .header-nav，它绑定了“这是页头里的导航”，一旦设计改了——导航挪到侧边栏，这个类名就既不准确又没法复用；而OOCSS会拆成 .nav（定义导航基础样式）+ .mod-header（定义页头容器的修饰），需要时组合：class="nav mod-header"。
- 类名不包含位置、内容、视觉效果等上下文信息（如
.blue-btn、.left-sidebar都违背原则） - 每个类只负责一个明确职责：结构（
.media）、皮肤（.skin-dark）、容器（.mod-card） - 组合使用是常态，不是例外；但避免深层嵌套（
.mod-card .media .img这种链式选择器要警惕） - 实际项目中，团队对「对象边界」的理解容易不一致，比如有人觉得
.btn是对象，有人觉得.btn-primary才算——这得靠约定，不是靠工具强制
怎么判断一个CSS类是不是OOCSS风格
看它能不能脱离当前HTML结构独立存在、被其他模块安全复用。如果删掉它所在的父元素或改个标签，样式立刻错乱，大概率不是OOCSS。
- 检查类名是否含语义绑定：
.article-title→ 绑定文章内容；换成.title更中性，但得确保所有标题共用同一套字号/行高逻辑，否则就是假抽象 - 查看CSS文件里有没有大量重复声明：比如5个模块都写了
margin-bottom: 1rem，说明缺一个.mb-1或.stack-sm这样的布局对象 - 注意伪类和状态是否被隔离：把
:hover写进.btn里，不如单独抽成.is-hovered，方便在非按钮元素上复用交互反馈 - 工具无法自动识别OOCSS，ESLint插件
stylelint-selector-bem-pattern只能检查BEM，对OOCSS无能为力——这事得人眼 Review
OOCSS和BEM、SMACSS这些方法论冲突吗
不冲突，但目标不同。BEM强调命名可读性和作用域隔离，SMACSS偏重目录与层划分，OOCSS专注「最小可复用单元」的设计粒度。
- BEM的
.block__element--modifier是一种实现OOCSS的方式，但不是唯一方式；你可以用.btn+.btn-lg+.btn-secondary，只要它们各自职责清晰、互不耦合 - SMACSS的「Layout」层常对应OOCSS里的容器对象（
.mod-grid、.mod-sidebar），但SMACSS没规定这些类内部怎么写 - 容易踩的坑是混用却不自知：比如写了
.card__header（BEM命名），但又给它加了margin-top: 2rem（强布局依赖），结果另一个地方想用卡片头却不敢复用——这不是BEM的问题，是没守住OOCSS的「对象应解耦结构与表现」原则 - 实际项目中，小团队直接用OOCSS+简单命名更轻量；大项目配合BEM能提升协作确定性，但得接受类名变长、组合增多
复杂点在于：OOCSS的有效性极度依赖团队对「对象边界」的共识。没人定义清楚 .form 是指表单容器，还是包含所有输入控件的基础样式，那写出来的代码看着像OOCSS，实则仍是散装CSS。
立即学习“前端免费学习笔记（深入）”；
