在 Figma 早期的设计系统实践中，搭建一个基础的按钮（Button）组件往往是一场“噩梦”：为了覆盖左图标显示/隐藏、右图标显示/隐藏、只显示图标、三种尺寸（Small/Medium/Large）、四种样式（Primary/Secondary/Outline/Ghost）以及五种交互状态（Default/Hover/Focus/Disabled/Loading），设计团队被迫在画布上排列出一个由数百个子组件组成的庞大变体矩阵（Variant Matrix）：

$$ 2 \times 2 \times 2 \times 3 \times 4 \times 5 = \mathbf{240\text{ 个变体！}} $$

这种变体爆炸（Combinatorial Explosion）不仅维护成本极其高昂，而且严重拖慢了 Figma 文件的加载速度与内存性能。

Component Properties（组件属性） 与 Slot（插槽） 思想的引入，彻底终结了这种野蛮膨胀。通过将显隐、文案与图标替换抽象为独立属性，原先需要 240 个变体的矩阵可以直降至 12 个变体以内！本文将系统拆解企业级高复用组件架构的核心法则。

---

1. 四大组件属性 (Component Properties) 深度对比

Figma 官方提供了四种正交属性，合理组合可以解决 90% 的状态流转：

属性类型	图标标识	作用对象	解决的核心问题与优势
Boolean Property	🔘 开关	任意图层的显隐（Visibility）	无需为“有无前置图标”、“有无徽标红点”创建翻倍的变体分支
Text Property	🔤 文案	任意文本图层的内容	业务设计师在右侧属性面板直接编辑文案，无需双击深层穿透选择文本
Instance Swap Property	🔄 替换	组件内部嵌套的子组件实例	限制只允许从特定的“图标库（Icon Library）”中选择替换，防止误换无效图层
Variant Property	🎛️ 变体	整个 Component Set 的宏观外观与尺寸	仅用于那些具有明显几何尺寸形变、物理结构变更的状态差异（如 Size、Type）

---

2. 实战重构：从 240 个变体缩减至 12 个变体

下面我们以工业级企业按钮为例，演示如何使用 Component Properties 完成极致重构：

第一步：锁定真正的宏观变体 (Variant Properties)

仅保留两个最核心的物理差异维度：

• Size（尺寸）: Small (32px) / Medium (40px) / Large (48px)（3 种尺寸）
• Theme（类型）: Primary / Secondary / Outline / Ghost（4 种样式）
• 此时变体总数仅为：$3 \times 4 = \mathbf{12\text{ 个主组件}}$！

第二步：配置 Boolean 属性控制图标显隐

1. 在母本中，放置左侧图标（Leading Icon）、中间文字、右侧图标（Trailing Icon）。
2. 选中左侧图标图层，在右侧面板 Layer 右侧点击创建属性图标（Create property）。
3. 命名为 Show Leading Icon，默认值设为 true。
4. 同样为右侧图标创建属性 Show Trailing Icon，默认设为 false。
5. 收益：无需创建任何额外变体，业务设计师在右侧面板通过一个 Toggle 开关即可自由决定是否显示图标！

第三步：配置 Instance Swap 限制图标范围

1. 选中左侧图标实例，在右侧 Component 属性区域点击 Create instance swap property。
2. 命名为 Leading Icon。
3. 关键高级设置：勾选 Preferred values（推荐值），将团队专用的 Icons/Navigation 库添加为首选库。
4. 收益：业务设计师在替换图标时，弹出的下拉菜单只展示标准图标库，绝不会把一个全宽卡片或表格误换进按钮里。

第四步：配置 Text 属性提升输入体验

1. 选中中间的文字图层。
2. 在右侧 Text 属性旁点击创建属性，命名为 Button Label，默认值填入 Button。
3. 业务设计师在画板中选中按钮实例后，右侧面板顶层直接展示一个清晰的单行输入框，敲击回车即可修改文案，彻底告别“双击进入第四层子节点修改文本”的繁琐操作。

---

3. Slot (插槽) 架构思想：解决高定制容器组件

在企业级后台界面中，诸如 Modal（对话框弹窗）、Drawer（抽屉）、Card（内容卡片） 属于“外壳容器组件”。其 Header（标题栏）与 Footer（底栏按钮）是高度固定的，但中间的 Body（内容区）却千变万化（有时是一张图表，有时是一个复杂表单，有时是一张表格）。

如果为每一种弹窗内容都去创建一个弹窗变体，设计系统将彻底失控。

现代化解法：Slot 插槽模式

┌────────────────────────────────────────────────────────┐
│ Modal Container Component (标准弹窗外壳主组件)           │
│  ┌──────────────────────────────────────────────────┐  │
│  │ Modal Header: [标题文本]               [关闭按钮 X] │  │
│  ├──────────────────────────────────────────────────┤  │
│  │ [Slot Component Placeholder: 占位插槽]           │  │
│  │  (默认放置一个 320x160 的基础占位符实例)            │  │
│  │  绑定 Instance Swap Property: "Content Slot"     │  │
│  ├──────────────────────────────────────────────────┤  │
│  │ Modal Footer: [取消按钮]              [确认按钮]    │  │
│  └──────────────────────────────────────────────────┘  │
└────────────────────────────────────────────────────────┘

业务落地应用流程

1. 设计系统团队在公共库中发布上述带有 Content Slot 属性的标准 Modal 外壳。
2. 业务设计师在自己的业务文件中，将实际的业务表单（例如“修改密码表单”）绘制为一个本地独立主组件。
3. 业务设计师调用公共库的 Modal 实例，在右侧面板的 Content Slot 属性下拉菜单中，选择自己的“修改密码表单”组件。
4. 完美契合：弹窗外壳遵循 Auto Layout 自动撑大包裹表单内容，标题栏和操作底栏依然受到公共库的统一规范约束，既保证了设计一致性，又赋予了业务侧 100% 的灵活性！

---

4. 架构审查与维护防劣化原则

1. 变体属性不超过 3 个维度： 如果一个组件的变体维度超过 3 个（例如同时包含 Type、Size、State、Theme、Shape），请立即停下，将其中的 State（如 Hover、Active）下放为交互式原型组件，将 Shape 或 Icon 转化为 Component Properties。
2. 避免过深的组件嵌套依赖 (Nesting Depth)： 组件嵌套不宜超过 3 层。A 组件嵌套 B，B 嵌套 C，C 嵌套 D 会导致渲染引擎陷入漫长的依赖拓扑遍历，引起画布卡顿。
3. 及时清理孤儿变体 (Orphan Variants)： 在组件重构后，务必在组件集内检查是否有尺寸未统一或已废弃命名的旧变体节点，保持组件集边界干净。