“组合优于继承”是vue组件设计应对业务复杂度的核心策略，即通过可插拔、可替换、可测试的组合单元（如usedraggable、pricecalculator、notifier）替代僵硬继承链，用props、slots和组合式api实现解耦与复用。
“组合优于继承”不是一句口号，而是 Vue 组件设计中应对业务复杂度的核心策略。它意味着把功能拆成可插拔、可替换、可测试的独立单元，再按需组装，而不是靠层层 extends 建立僵硬的类关系。
明确能力边界，按“能做什么”而非“是什么”来建模
继承天然适合表达“是一个”关系（比如 AdminUser 是 User），但业务组件多数时候要解决的是“能做什么”——比如“支持拖拽”“可排序”“带价格计算”。这类行为不该绑定在某个父类里，而应抽成独立的能力模块：
- 把 拖拽逻辑 封装为 useDraggable() 组合函数，任何组件都可以调用
- 把 价格计算规则 抽成 PriceCalculator 接口，VIP 订单用 VIPPriceCalculator，秒杀订单用 FlashSaleCalculator
- 把 通知方式 设计为 Notifier 实现类，邮件、站内信、Webhook 各自独立，运行时注入
用 props、slots 和组合式 API 替代继承链
Vue 的响应式系统和模板机制天然支持组合：
-
props 传递配置和数据，让父组件控制子组件行为（如
size="large"、disabled） - slots 注入内容与结构，实现视觉和布局解耦（如 header 插槽、item 插槽）
-
组合式 API（
setup()+useXXX()）复用逻辑，避免 mixins 的命名冲突和隐式依赖
像 Vuetify 的 VBtn 或 VDataTable，所有变体都通过属性开关和插槽定制，而不是靠 VPrimaryBtn、VOutlinedBtn 这类继承子类。
Vue Composition Analyzer
下载
分析 Vue 3 Composition API 使用情况——审计响应式模式、可组合函数设计、ref 与 reactive 的选择、计算属性、watcher 使用及组件……
警惕继承滥用的三个信号
当出现以下情况，说明继承正在拖累开发效率：
- 子组件重写了父组件 70% 的方法，只保留一两个 super 调用
- 某个子类完全不用父类里的支付校验逻辑，但删掉就会报错（因为其他子类依赖）
- 为支持“定时发布订单”，不得不新增一个
ScheduledOrder类，但它和NormalOrder并不构成“是一种”的关系，只是多了个字段和定时任务
这时该做的不是加一层继承，而是把“定时发布”拆成一个可选的调度能力组件，组合进订单流程中。
保留继承仅用于真正共享的骨架
不是彻底禁用继承。如果多个组件确实共用一套不可变的执行框架，比如：
- 统一的日志埋点模板
- 事务开启/提交/回滚的标准流程
- 异常统一包装和上报机制
可以抽象出一个基类，但里面只放模板方法和钩子，所有具体判断和业务逻辑必须下沉到组合进来的策略组件里。这样骨架稳定，能力灵活，各司其职。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
