聊到OOCSS，很多人第一反应是"多写两个class"，走个形式就完了。其实不然——真正有价值的地方在于：同一组DOM结构，通过组合不同的class列表，能低成本地变出多种视觉形态。这个复用能力，就藏在class组合的排列组合里。
长期稳定更新的攒劲资源： >>>点此立即查看<<<
结构与皮肤分离的核心命题，不是形式主义，而是让同一组 DOM 能通过组合不同类名，低成本生成多种视觉变体——复用性就藏在 class 列表的排列组合里。
什么是结构类和皮肤类
结构类负责组件的"骨架"：尺寸、间距、显示方式、边框圆角这些跟颜色无关的布局规则；皮肤类只管"颜值"：背景色、文字色、阴影、过渡动效等。两者互不牵制，可以自由拼接。理解OOCSS如何提高代码复用性，首先需要掌握这两类各自的分工与边界。
一个常见踩坑：把.btn-primary写成一个万能大杂烩类，既设padding又管background-color——结果换肤的时候只能复制整段样式，或者祭出!important来覆盖。这种写法恰恰违背了CSS设计模式中关于关注点分离的基本原则。
正确姿势是这样的：
.btn { display: inline-block; padding: 8px 16px; border-radius: 4px; font-size: 14px; }.btn--primary { background-color: #007bff; color: white; }.btn--outline { border: 1px solid #007bff; color: #007bff; background: transparent; }
这样和共用结构骨架，只需要替换皮肤部分。这种组合方式正是OOCSS如何提高代码复用性的典型实践。
为什么不能用后代选择器写皮肤
.card .btn这种写法，本质上把皮肤逻辑锁死在了特定容器里。哪天这个按钮要挪到弹窗或者侧边栏里，样式立马失效——要么重写，要么加权重覆盖。这种耦合关系会直接拖累CSS文件的简化与维护效率。
更麻烦的是，它让皮肤失去了独立性：你没法单独测试.btn--primary在不同上下文里是否生效。坚持原子化的类名，才能确保每个皮肤类在任何位置都管用，这也是将结构与皮肤分离简化CSS文件的关键所在：
-
.btn--primary直接作用于元素本身 -
.card .btn-primary依赖父级存在 -
.btn.primary（无连字符）语义模糊，容易跟BEM的modifier搞混
结构类要不要带尺寸
当然要，但颗粒度得控制好。结构类负责"基础形态"——比如.btn定义默认内边距和圆角；而尺寸变体像.btn--sm、.btn--lg，应该归为结构扩展，不是皮肤——因为它们改变的是布局属性（padding、font-size），跟视觉风格无关。在CSS设计模式中，这种分层管理是提高代码复用性的核心手段。
容易踩的坑有几个：
- 把
font-size丢进皮肤类 → 导致字号随主题切换乱套 - 把
border-radius放皮肤类 → 圆角成了"视觉装饰"，实际是结构特征 - 用
@extend把皮肤扩展给结构 → 编译出来一堆冗余选择器，原子性全丢了
判断标准其实简单：这个属性改了，会不会让组件在页面上"站不住"（布局塌陷、溢出、对不齐）？会，那它就属于结构。坚持这一原则，才能真正做到将结构与皮肤分离简化CSS文件。
如何避免结构类膨胀成"万能工具箱"
结构类不是越通用越好的。像.flex-center、.text-truncate这类纯工具类，不应该混进组件结构里——它们属于utils/层，跟.btn压根不是一个抽象层级。区分清楚这些边界，是掌握OOCSS如何提高代码复用性的进阶要点。
OOCSS的结构类必须绑定具体语义组件：
-
.btn、.card、.form-field -
.d-flex、.m-2（那是Utility-First CSS的思路，跟OOCSS不兼容）
如果结构类越写越像一堆零散工具类堆砌出来的效果，那就本末倒置了。真正的复用，来自语义明确、职责清晰的类组合——而不是把CSS都塞进HTML里，搞得像"CSS in HTML"的反模式。始终围绕CSS设计模式的核心思想来组织代码，才能让复用性和维护性兼得。
