获课：itazs.fun/18777/

拒绝“过度封装”：在通用性与灵活性之间寻找组件抽象的“黄金分割点”

在前端开发的漫长演进中，我们似乎总是陷入一种“造轮子”的狂热，或者更准确地说，是“造超级轮子”的执念。每当面对重复的业务场景——那些千篇一律的“筛选+表格+弹窗”页面时，一种源自工程师本能的焦虑便会油然而生：如果我不把它们抽象成一个通用的组件，那我岂不是在做无用功？于是，我们开始了一场关于“过度封装”的冒险，试图构建一个能够吞噬所有业务差异的“上帝组件”。然而，这种对通用性的极致追求，往往让我们掉进了“越通用越不通用”的陷阱。在我看来，组件抽象的艺术，本质上是在寻找通用性与灵活性之间的“黄金分割点”，这不仅关乎代码质量，更关乎一种对复杂度的克制与权衡。

我们首先要警惕的，是那种试图用配置项覆盖所有可能性的“万能组件”思维。这种思维模式往往源于对未来的过度防御。我们害怕未来某天会出现一个特殊的需求，于是提前在组件里预埋了二十个属性，试图把表格做成能排序、能筛选、能树形展示、能合并单元格的“瑞士军刀”。但现实往往是残酷的：这种高度抽象的组件，最终变成了一个难以维护的“黑盒”。当业务方仅仅想要一个简单的列表时，却被迫引入了沉重的通用框架；而当业务方真的遇到那20%的特殊交互时，又发现原本引以为傲的配置化方案束手无策，只能被迫使用各种“魔改”的插槽去修补。这种“为了复用而复用”的抽象，实际上制造了更高的认知负荷和维护成本，它违背了KISS原则，让简单的逻辑淹没在层层包裹的抽象之中。

那么，真正的“黄金分割点”在哪里？我认为，核心在于对“职责边界”的清醒认知。优秀的组件抽象，不应追求大而全的“上帝视角”，而应遵循“80%通用+20%灵活扩展”的策略。这80%的通用部分，是那些真正高频、稳定且无业务属性的基础能力，比如数据的加载状态管理、分页逻辑、基础的表单校验等。这些是“骨架”，必须稳固且统一。而那20%的灵活部分，则是业务逻辑的“血肉”，必须通过插槽或回调函数完全交给使用者去定义。

我们要学会将“逻辑”与“表现”剥离，将“容器”与“UI”解耦。一个健康的组件设计，应该是“状态外置，逻辑内聚”。组件内部只负责处理最纯粹的行为逻辑，比如“点击按钮后触发校验”，而“校验通过后做什么”、“数据从哪里来”，这些涉及具体业务上下文的东西，必须由外部传入。这就好比我们设计一个插座，插座的标准（电压、孔距）是通用的，但插在上面的电器是千变万化的。如果我们在插座里内置了微波炉的逻辑，那它注定无法兼容电视机。

此外，我们必须承认“简单粗暴”在特定阶段的价值。在业务探索期或需求尚不明朗时，过早的抽象就是一种负债。 Kent Beck提出的“三次原则”至今仍是金科玉律：同一个模式只有在第三次出现时，才值得考虑抽象。在此之前，复制粘贴虽然看起来不够优雅，但它保留了代码的可读性和修改的灵活性。只有当重复带来的痛苦超过了抽象带来的复杂度时，重构的时机才算成熟。

最终，组件抽象的终极哲学，不是为了写出看起来“高大上”的代码，而是为了降低系统的熵增。我们需要在“重复劳动”与“过度设计”之间走钢丝。真正的智慧，是懂得何时该通过抽象来消除重复，何时该通过解耦来拥抱变化。拒绝过度封装，就是拒绝那种试图用一套规则解释宇宙的傲慢，转而拥抱一种更加务实、更加开放、更加尊重业务多样性的工程文化。在这个人机共生的时代，让AI去处理那些繁琐的重复代码，而我们人类开发者，则应专注于界定这些组件的边界，守住那些机器无法理解的复杂业务价值与交互体验。