vue.js中“组合优先于继承”是务实选择，通过props、slots和composition api实现松耦合、高复用、易维护的组件设计，避免继承带来的刚性依赖与调试难题。

Vue.js 中“组合优先于继承”不是一句口号，而是在长期实践中沉淀出的务实选择。它指向一种更可控、更易维护、也更符合 Vue 响应式哲学的设计思路——用灵活的组装代替刚性的层级依赖。

为什么组合比继承更稳妥

继承容易把组件逻辑绑死在父类结构里。一旦基础组件内部实现调整（比如数据格式变更、生命周期钩子重写），所有子组件都可能意外失效；而组合通过 props、slots 和 事件通信 建立松耦合连接，父组件改了什么，只要接口没变，使用者完全不受影响。

• 继承关系在编译时固化，运行时无法替换或动态切换行为
• 子组件会暴露并依赖父组件的内部细节（比如 data 字段名、method 名），形成隐性契约
• 多个功能叠加时，继承链容易变得难以理清（A → B → C → D），调试和测试成本上升
• 组合则允许你在任意层级插入、替换、复用逻辑块，比如用一个 useForm 组合式函数统一处理表单校验，而不是为每个表单组件写一套继承体系

组合怎么落地：三个核心手段

Vue 提供了天然支持组合的语法糖和机制，不需要额外框架就能写出清晰可复用的组件：

• Props + Emits：定义明确的输入输出边界。例如一个按钮组件只接收 size、variant 和 click 事件，不关心它被用在弹窗还是表格操作栏
• Slots（尤其是作用域插槽）：把渲染权交给使用者。像分页组件提供 #item 插槽，让调用方决定每条数据怎么展示，而不是靠继承后重写模板
• Composition API（setup / useXXX 函数）：把逻辑抽成独立函数，按需导入。比如 useFetch、useDebounce 可以被任意组件复用，无需继承任何“网络基类”或“防抖基类”

继承不是不能用，而是要谨慎评估

Vue 仍支持 extends 和 mixins（尤其在遗留项目中），但官方已明确不推荐在新项目中滥用。只有当以下条件同时满足时，才值得考虑继承：

dmap-jsapi-skill

DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。

下载

• 存在一组高度稳定、极少变动的基础行为（如统一的日志上报逻辑、权限拦截钩子）
• 子组件与父组件语义上确属“is-a”关系（比如 PrimaryButton 是 BaseButton 的一种），而非“has-a”或“uses-a”
• 团队对继承链有清晰文档和管控机制，避免多层嵌套和覆盖冲突

多数时候，一个封装好的 defineComponent 配合 defineExpose，再加几个通用 hooks，比写五层继承更直观、更易测试。

实际对比：一个表单场景

假设要做登录、注册、重置密码三类表单，它们共享字段校验、提交状态、错误提示逻辑：

• ❌ 继承方案：建一个 BaseForm，让三个组件 extend 它，各自重写 template 和部分 methods —— 一旦 BaseForm 升级，三个地方全得回归测试
• ✅ 组合方案：抽一个 useForm({ fields, rules })，每个表单组件独立 import 并调用，模板完全自主控制，逻辑复用但视图解耦

后者修改成本低、职责清晰、单元测试容易覆盖，也方便未来把某一个表单迁移到其他技术栈。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！