参数过多的组件难以正确使用
别名: 参数汤 · 布尔爆炸 · boolean explosion · 属性过载
概念解释
每个公开参数都是一个维度。维度一多，合法组合按指数涨，而设计过、测试过的组合仍接近作者脑子里那几条快乐路径。调用方在文档和自动补全里看见二十个开关，只能猜。猜错的调用看起来「在用系统」，实际走出了从未被规定的态。参数汤（prop soup）说的是公共表面超出可把握的范围之后，正确使用不再是默认结果。它不管抽象来得早或晚，也不管该不该再等一次重复——汤已经盛在碗里，问题是这碗没法被准确舀。
机制
N 个相互独立的布尔量给出 2^N 种配置。人的工作记忆装不下这张表，文档也很少穷尽。于是「正确用法」只存在于作者的示例文件里；示例覆盖不了的格子，由调用方用直觉填。直觉会同时打开互斥的开关、会把视觉参数和语义参数叠在一个名字下、会在空态上再开加载。组件内部若用一长串条件去消化这些组合，未设计的格子会掉进空白、错位或互相覆盖的样式。对外，调用点看起来各写各的，因为汤没有一条能被复述的调用公约。参数越多，公约越不可能形成：能被记住的只有三到五个常用搭配，其余都是暗门。暗门一旦被用进生产，再删参数就变成破坏性变更。汤会自我加厚：每一次误用都催生「再加一个开关来禁止那种误用」。
边界
底层原语（原生输入、底层堆叠）参数天然多，那是平台契约，靠的是平台文档和语言服务，不是设计系统里的业务组件。业务组件若参数数量接近原语，通常是把好几件职责揉进了一个名字。配置对象或插槽可以把表面看起来变短，若对象内部仍是互不约束的一包开关，汤只是换了容器。设计工具里的变体面板也会煮汤：变体轴过多时，设计师同样无法预知组合。有些组合非法且被类型系统拒绝，有效空间会下降，这是在治汤；只在运行时警告、类型上仍全开，调用方在写代码时仍然在猜。单次使用的局部件参数多一点可忍受，因为它的调用公约就是那一处代码；一旦共享，公约必须能离开作者的脑子。
怎么落地
- 给每个共享组件列一张「支持的调用公约」：不超过若干条完整示例，每条对应一种真实职责。公约之外的参数组合标为非法，用类型或运行时断言挡住，而不是默默渲染。
- 互斥的维度做成枚举，不要做成两个布尔。发现文档要用真值表才能说明，就拆成两个组件或改用组合，而不是再写一段「请勿同时开启」。
- 新增参数的默认门槛：它是否消灭一条现有公约，或只是给某一页开暗门。暗门不进公共表面。
- 验证：找一个未写过该组件的工程师，只给公约示例，让他实现一个中等页面。第一次调用就打开示例里没有的开关、或问「这两个能不能一起开」，汤已经在发挥作用。统计公共参数个数与类型可表达的合法组合数：合法组合远大于公约条数，多出来的格子就是误用的培养基。打开生产里的实际调用，对照公约，违约比例就是「难以正确使用」的度量，不是观感。