前端组件边界怎么划

组件化是前端最常见的工程手段，但“拆组件”并不天然等于代码更好。一个页面拆得太少，会出现巨型文件；拆得太碎，又会让状态传递和事件追踪变复杂。判断组件边界时，我通常先看职责是否独立，而不是看 DOM 有多少行。

一、先区分容器和展示

容器组件关心数据从哪里来、什么时候加载、用户动作如何提交；展示组件关心数据如何呈现、交互控件如何排列、空状态和错误态如何展示。两者混在一起时，组件会既要懂接口，又要懂布局，还要懂业务规则，后续改动很容易牵一发动全身。

一个实用判断是：如果拿掉接口请求，这个组件还能不能独立预览？如果能，它更像展示组件；如果不能，它可能是页面级容器或业务容器。

二、数据流要单向清楚

组件边界不清时，最常见的问题是子组件偷偷改父组件数据，或者多个兄弟组件互相依赖隐含状态。更稳的做法是父组件负责状态归属，子组件通过 props 接收数据，通过事件表达意图。事件名也要表达业务动作，例如 submit、remove、select，不要用含糊的 change 承载所有事情。

三、复用要算维护成本

很多组件一开始为了复用被做得过于通用，最后 props 越加越多，插槽越来越深，调用方越来越难懂。业务组件的复用应该有明确场景，如果只是两个地方看起来相似，但业务规则、权限、交互反馈都不同，硬抽一个通用组件反而会增加成本。

• 稳定复用的 UI 结构可以抽成基础组件。
• 业务规则相同的流程可以抽成业务组件。
• 只有视觉相似但业务不同的块，先允许重复。
• 组件暴露的 props 越多，越要警惕边界已经失控。

好的组件边界会让改动位置变得可预测：改样式找展示组件，改数据流找容器组件，改业务规则找业务流程，而不是每次都全局搜索。