vue组件体系的核心是拆解问题的思维方式，即将界面视为可组装、可替换、可验证的功能单元；组件应遵循单一职责、契约化通信、插槽即接口、复用需收敛四大原则。
Vue 组件体系的核心，不在语法细节，而在一种拆解问题的思维方式——把界面看作可组装、可替换、可验证的“功能单元”，而非一整块需要通盘处理的 HTML。
组件不是容器，是职责边界
一个组件该有多大？关键不在于代码行数，而在于它是否只做一件事。比如一个“地址选择器”，如果同时承担地址展示、编辑弹窗、默认设为收货地址、校验手机号格式、调用高德地图 API 等五种逻辑，它就已违背单一职责。理想状态是：展示用 AddressItem，编辑用 AddressEditor，设为默认用 SetAsDefaultButton，各自独立开发、测试和复用。
- 判断标准：改一处逻辑，是否可能影响其他业务场景？如果会，说明职责过重
- 命名提示：组件名带连字符（如
OrderSummaryCard）比泛称（如Content）更能体现边界 - 副作用收敛：API 请求、本地存储、路由跳转等副作用，应尽量封装在父组件或组合式函数中，子组件专注接收 props、触发事件
通信不是传递数据，是定义契约
父子通信不是“把数据塞过去”，而是明确谁提供什么、谁响应什么。props 是输入契约，events 是输出契约，v-model 是双向契约的语法糖。
vue-component-analyzer
下载
递归分析 Vue 项目组件依赖，从入口文件生成组件层级图，支持 Vue 2/3，输出组件名、文件路径和属性。适用于分析组件结构、排查依赖或了解项目架构。
- 避免深层透传：A → B → C → D 才到目标组件？考虑用 provide/inject（跨层级共享配置类数据）或 Pinia（状态驱动型逻辑）
- 事件命名用动词过去式：用
@address-selected而非@change，语义更明确 - 复杂数据建议封装成对象 prop：比如传
address对象，而不是分别传name、phone、province等 7 个 prop
插槽不是占位符，是开放接口
插槽本质是组件对外暴露的“内容定制权”。默认插槽适合内容主体可变，具名插槽适合固定区域定制（如 header/footer），作用域插槽则把内部状态“托付”给使用者。
- 有默认行为时，插槽应提供 fallback：例如按钮组件内，
<slot>点击我</slot>保证无内容时不空白 - 作用域插槽传参要精简：只暴露必要字段，比如
item和index，别把整个响应式对象全抛出去 - 避免插槽嵌套过深：三层以上插槽链会让调用方难以理解数据流向，此时更适合拆成多个组件协作
复用不是到处引用，是收敛管理
真正可复用的组件，一定经过抽象、约束和沉淀。不是每个页面都用的组件就该全局注册；高频、稳定、低业务耦合的才值得放入 UI 库。
- 局部注册优先：仅在单个页面使用的组件，直接在
components选项里声明，避免污染全局命名空间 - 提取通用逻辑：把表单校验规则、列表加载状态、空态文案等，抽成可组合的
useFormRules、useListLoading等函数 - 版本意识：团队级组件库需遵循 SemVer，小修用 patch（1.2.3），新增 API 用 minor（1.3.0），破坏性变更用 major（2.0.0）
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
