Vue 项目做久了，大家都会遇到一个阶段：组件越来越多，但不是越多越清楚，而是越多越难改。
典型表现是：
- 一个组件 props 很多，但真正的核心输入并不明确
- 事件命名随业务演化，父子通信越来越绕
- UI、请求、副作用和状态混在一起，组件表面上复用，实际上难以维护
所以组件设计模式真正解决的，不是“怎么写得优雅”，而是“以后改功能时，会不会不断把复杂度推高”。
如果你在做组件库或页面结构治理，建议一起看 组件库架构设计实践、Vue 项目目录怎样更适合 AI 协作 和 构建高性能富文本编辑器。
模式一：Props/Events 适合表达清晰输入输出
绝大多数业务组件，先用最朴素的 props + events 就够了。
关键不是“有没有 advanced pattern”，而是：
- 输入是不是有限且清晰
- 输出是不是围绕用户动作，而不是内部实现细节
一个更稳的规则是：
- props 描述外部输入和配置
- emits 只描述用户意图和结果状态
- 不要把内部中间状态全部抛给父组件
如果组件的对外契约说不清，后面再高级的模式都只是把混乱包装得更漂亮。
模式二：容器组件和展示组件分离
当组件同时承担：
- 数据获取
- 权限判断
- 视图渲染
- 空态/错误态控制
它通常已经过载了。
更稳的拆法是：
- 容器组件负责数据与副作用
- 展示组件只负责 UI 和用户交互
这不是为了教条式分层，而是为了让渲染层更可测试、更可复用。
模式三：Slots 比“万能 props”更适合处理局部差异
很多团队一看到视觉差异，就想继续加 props：
showIconiconPositionextraFootercustomEmptyText
短期方便，长期很容易把组件做成参数迷宫。
如果差异发生在局部结构上，slot 往往更稳：
- 基础组件保留稳定骨架
- 调用方通过 slot 定制局部区域
- 组件维护者不需要为每种业务分支持续加参数
模式四：Renderless 组件适合复用交互逻辑，不适合拿来炫技
Renderless 模式真正有价值的场景是：
- 交互逻辑复杂，但视觉承载差异很大
- 例如自动完成、拖拽排序、键盘导航、搜索建议
它的核心收益是“复用行为，不绑定 UI”。
但如果只是一个普通弹窗、普通列表，硬上 renderless 往往只会增加理解成本。
模式五：组合式函数负责逻辑提取，组件仍要保留清晰职责
Composition API 让逻辑提取非常方便，但也带来了另一类问题：
- 逻辑被提走后，组件本身反而没人维护结构边界
- composable 越写越重，变成隐形 service 层
更好的做法是：
- composable 抽离可复用逻辑
- 组件仍然承担清晰的交互和渲染责任
- 不要让 composable 变成“什么都知道的万能黑盒”
失败案例：为了复用，把一个业务组件抽成了错误的基础组件
很常见的一种过度抽象是：
- 看到三个页面都有“筛选卡片”
- 立刻抽成一个基础组件
- 后续每个页面都在加条件，最后 props 和 slots 越来越多
问题不在复用，而在抽象层级错了。真正应该复用的也许不是整个卡片，而是：
- 筛选项布局
- 状态同步方式
- 提交与重置按钮区
不是所有“看起来差不多”的组件，都值得抽成同一个基础单元。
怎么判断一个模式值不值得用
可以先问 4 个问题：
- 这个模式是在减少复杂度，还是在转移复杂度
- 它解决的是当前高频问题，还是未来假想问题
- reviewer 能否快速理解这个组件的输入输出边界
- 一个月后新同事接手时，能否迅速定位问题所在
如果这些问题答不清，就说明还没到引入更复杂模式的时候。
一份可直接复用的检查清单
- props 是否只承载必要输入，而不是历史兼容集合
- emits 是否表达用户动作，而不是内部实现状态
- 容器逻辑和展示逻辑是否混在一起
- 结构差异是否应该用 slots，而不是继续加 props
- renderless 是否真的复用了复杂行为，而不是为了抽象而抽象
- composable 是否保持单一职责，没有变成隐形万能层
总结
Vue 组件设计模式的核心，不是追求模式数量，而是用最小复杂度换取最长的维护稳定性。先把输入输出边界做清楚，再决定是否引入 slot、容器分层、renderless 和 composable，组件体系才会越做越稳。
进一步阅读：
