皮肤结构分为表皮、真皮和皮下组织三层；表皮含角质层、透明层、颗粒层、棘层和基底层，真皮分乳头层和网状层，皮下组织主要由脂肪构成，共同实现保护、感觉、调节等功能。
结构与皮肤分离不是“多写两个类”的形式主义，而是让同一组 DOM 能通过组合不同类名，低成本生成多种视觉变体——复用性就藏在 class 列表的排列组合里。
什么是结构类和皮肤类
结构类定义组件的布局骨架：尺寸、间距、显示方式、边框圆角等不依赖颜色/背景的规则；皮肤类只管视觉表现：背景色、文字色、阴影、过渡动效等。两者互不耦合，可自由拼接。
常见错误是把 .btn-primary 写成一个大而全的类，既设 padding 又设 background-color，导致换肤时必须复制整段样式或加 !important 覆盖。
正确做法示例：
立即学习“前端免费学习笔记（深入）”；
.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; }
这样 <button class="btn btn--primary"> 和 <button class="btn btn--outline"> 共享结构，只替换皮肤。
为什么不能用后代选择器写皮肤
像 .card .btn 这类后代选择器会把皮肤逻辑锁死在特定容器里，违背“分离容器与内容”原则。一旦按钮要挪到弹窗或侧边栏，样式就失效，只能重写或加权重覆盖。
更糟的是，它让皮肤失去独立性：你无法单独测试 .btn--primary 在任意上下文是否可用。
应坚持原子化类名，确保每个皮肤类在任何 HTML 位置都生效：
- ✅
.btn--primary直接作用于元素本身 - ❌
.card .btn-primary依赖父级存在 - ❌
.btn.primary（无连字符）语义模糊，易与 BEM 的 modifier 混淆
结构类要不要带尺寸？
要，但得控制粒度。结构类负责“基础形态”，比如 .btn 定义默认内边距和圆角；尺寸变体如 .btn--sm、.btn--lg 应归为结构扩展，而非皮肤——因为它们改变的是布局属性（padding、font-size），不是视觉风格。
容易踩的坑：
- 把
font-size放进皮肤类 → 导致字号随主题切换错乱 - 把
border-radius放进皮肤类 → 圆角变成“视觉装饰”，实际是结构特征 - 用
@extend把皮肤 extend 给结构 → 编译后仍生成冗余选择器，失去原子性
判断标准：这个属性改了，是否会让组件在页面上“站不住”（布局塌陷、溢出、对齐错位）？如果是，它属于结构。
如何避免结构类膨胀成“万能工具箱”
结构类不是越通用越好。例如 .flex-center 或 .text-truncate 这类纯工具类，不该混进组件结构中——它们属于 utils/ 层，和 .btn 是不同抽象层级。
OOCSS 的结构类必须绑定具体语义组件，比如：
- ✅
.btn、.card、.form-field - ❌
.d-flex、.m-2（这是 Utility-First CSS 的思路，和 OOCSS 不兼容）
否则结构类会退化为“CSS in HTML”的反模式，失去组件封装价值。真正的复用，来自语义明确、职责清晰的类组合，而不是靠一堆零散工具类堆砌出按钮效果。
