R1.02.2combinatorial variant explosion设计
变体数量爆炸意味着抽象错误
别名: 变体爆炸 · 组合爆炸 · variant explosion · 错误抽象
概念解释
尺寸 × 语气 × 图标 × 加载 × 形状一旦乘出几十上百个变体，问题通常不在「还没画完」，而在轴选错了。组合爆炸（combinatorial explosion）是诊断信号：有的轴其实是另一个组件，有的轴其实是插槽里的内容，有的轴彼此并不独立，不该做成可自由相乘的开关。
它读的是矩阵结构对不对，不是「抽象得太早」那种时间问题，也不是名字起得太泛、什么都往里塞那种命名问题。格子多到维护不过来，说明切法本身坏了。
机制
变体轴被默认当成正交：每一轴上的取值可以和另一轴任意搭配，实现按乘积分支。真实产品里很多轴并不正交——「加载中」几乎总是发生在主按钮而不是文字链，「圆形」只和图标按钮共存。把非正交轴做成独立开关，矩阵里会填满从未合法过的空格子，每一格还要画状态、写测试、跟版本。维护成本按乘积涨，合法用法按加法涨，缺口就是爆炸本身。
正确的收缩不是删几个不常用的格子应付过去，而是重新划轴：把不独立的取值收成少数几个模式，把内容交给插槽，把其实是另一种控件的形状拆成另一个组件。爆炸是在告诉你「这不是一个带很多开关的东西」，而不是「开关还不够多」。
边界
无障碍要求的对照组合（强制高对比下一套完整色）会让格子变多，那是合规成本，不是抽象错误。平台差异造成的两套实现（桌面菜单 vs 移动动作表）也不该被压进同一条变体轴。设计工具里为演示展开的排列，如果从未进入代码，只是画布噪音，不要用它来判代码库爆炸。爆炸的判据是代码里的公开 API 乘积，不是 Figma 里排了多少帧。
怎么落地
- 列出该组件每个公开轴及取值个数，算出乘积；再列出生产里真正出现过的组合数。两者差一个数量级，就停下来改轴，不要继续补格子。
- 把几乎总是绑在一起的取值收成命名模式（如「图标圆钮」），不要再拆成「形状 × 是否有图标」。
- 把自由内容（图标、额外文案）改成插槽，从变体轴上拿掉。
- 验证：改轴后公开乘积应落到可逐格评审的规模，且原先的高频调用仍能表达。乘积没降、只是把格子藏进布尔 prop，爆炸还在。