企业官网建设流程全解析

写 Vue 组件这事儿，看起来简单，但真到项目里改了三个月，你会发现当初随手拆的组件全是坑。高内聚、低耦合，这八个字是组件设计最核心的原则，但也是最容易被忽略的。今天我不讲空话，直接聊聊怎么把一个 Vue 组件设计得既内聚又独立，能自己闭环，也能跟外界干净利落地交流。这篇文章适合正在写业务组件、打算搭组件库、或者被组件复用折腾到头疼的同学。

先说个我自己的经历。以前接手的项目里有一个“多功能弹窗组件”，props 有二十多个，内部状态跟外部状态搅在一起，一个窗口里既管表单校验又管数据请求还管动画。结果每次产品提需求，都得先把这个组件的所有调用方翻一遍，改一处崩三处。后来我把这个组件按高内聚低耦合的思路重写，拆成三个组件，对外只暴露几个必要参数，瞬间世界清净了。这就是今天要讲的核心。

1. 先搞清楚高内聚和低耦合到底在说什么

1.1 高内聚：组件内部的事，自己闭环

高内聚的意思是，一个组件内部的逻辑、状态、样式、行为都应该围绕同一个职责来组织，而且这个职责必须单一。换句话说，组件内部的这些要素彼此紧密相关，形成一个不可分割的整体。拆开来看，就好像一个工具箱里只放同一种用途的工具，而不是什么都往里面塞。

举个例子，一个搜索框组件，它的内部应该只关心：输入框的值从哪里来、用户输入后怎么触发搜索、搜索的 loading 状态怎么展示、结果列表怎么渲染。这些逻辑是天然内聚的，因为它们都服务于“搜索”这一个动作。如果你在一个搜索框组件里顺手处理了下拉菜单的其他业务逻辑，那就是把不相关的内聚单元混在一起了。

判断一个组件是否高内聚，有个很实用的方法：给这个组件写一段功能描述，如果描述里出现了“并且”“同时”“还要”这类词，那大概率是职责过多了。比如“这个组件展示表单，并且校验，同时还能做权限判断”，这就不是一个高内聚的组件了。

1.2 低耦合：对外界的依赖，减到最少

低耦合关注的是组件与外部的关联程度。一个低耦合的组件，对外部环境的依赖是可控的、明确的、可替换的。它不应该知道调用方是谁，也不应该直接操作全局状态，更不应该在内部偷偷依赖另一个组件内部的方法。

怎么理解？你可以把一个组件想象成手机充电器。充电器只需要知道输入 220V 交流电、输出 5V 直流电，它不用关心插头上的插座是哪个牌子的，也不用关心手机内部是哪颗电池。组件也是这个道理：它只通过约定的接口（props、事件、插槽）与外部交流，至于外部是谁，它不管。

低耦合带来最直接的好处是可替换性。如果组件 A 和组件 B 之间没有直接依赖，那么当你需要替换 A 的实现时，只要保证接口不变，B 都不用动。反过来，如果 A 内部直接调用了 B 的方法，那替换成本就直线上升。

1.3 一个反例：那些看起来能用、改起来要命的组件

我先描述一个很典型的反例，你看看眼不眼熟。某个项目里的列表组件，它接收一个数组，然后渲染列表项。但组件内部为了“方便”，直接引入了 Vuex 的 store 来读取用户信息，还通过this.$parent调用了父组件的某个方法去刷新数据。看起来功能都实现了，但一旦你想把这个列表组件拿到另一个项目用，就得把 store 也带过去，把父组件的方法也带过去。这哪里是复用，简直是搬家。

更难受的是，当你需要给列表增加筛选功能时，你发现在组件内部和 store 里都写了筛选逻辑，两边互相覆盖，查 bug 得查一整条链路。这就是典型的高耦合低内聚的产物。我在实际重构时遇到过很多这种组件，我的经验是：如果改动一个组件需要同时改动五个文件，先不要急着加功能，先重新划边界。

2. 从 API 设计开始：好的组件边界是“用起来舒服”

2.1 props 设计：只暴露必要的外部接口

props 是组件对外的第一层边界。设计 props 时，最忌讳的就是“防御性编程式”地堆参数。你暴露的每个 prop，其实都是在跟调用方说：“我要依赖你提供这个东西。”所以 props 越少，组件的耦合度越低。

我常用的原则是：能通过计算得到的值，不要做成 prop；能在组件内部默认处理的逻辑，不要要求外部传入；只有真正需要外部控制的，才用 prop 暴露。比如一个分页组件，当前页码和每页条数是必须由父组件控制的，那就用v-model:page和v-model:pageSize暴露；而分页跳转的步进大小，如果 90% 场景都默认是 5，那就在组件内部写个常量，不要开放 prop。

另外，props 需要定义类型、默认值和校验。这不是为了好看，而是为了在开发阶段尽早暴露问题。很多同学写 props 不写类型，传进来一个字符串当数组用，结果在模板上理解说话不对效果。用type和validator可以让错误在控制台直接打出来，调试成本降低一大截。

2.2 事件与 v-model：让父子通信清晰

对外输出行为用事件，这是组件增强耦合度最低的方式。父组件通过@event监听子组件的动作，子组件不知道父组件如何处理，两者只通过事件名称和数据约定耦合。

Vue 3 里推荐用defineEmits明确声明组件会触发哪些事件。这不仅是文档，也是一个契约。我建议事件命名采用“动词+名词”的结构，比如update:visible、select-change、search-submit。这样读到事件名就能猜出用途，不会出现一个叫change的事件既用来通知值变化又用来通知点击的情况。

v-model是一个更甜的点。当组件需要对外暴露一个可读写的值时，直接实现v-model是最符合用户直觉的。你不需要在组件内部感知到父组件的存在，你只在值变化时触发update:modelValue事件。父组件用自己的变量绑定这个值，双向通信就完成了。这比sync修饰符直观得多，也比$emit('change', value)再加一个valueprop 的方式简洁。

2.3 插槽：把自由度交给调用方

插槽是 Vue 组件低耦合的法宝之一，因为它能把“组件的内部结构”和“外部想要展示的内容”解耦。一个组件如果把内容区域写死，那么它的复用范围就非常有限；但如果通过插槽开放填空，那么组件只负责布局和逻辑，具体的内容由父组件决定。

这里有个深度问题：普通插槽和具名插槽怎么选？我一般这样判断：如果组件只有一个可以替换的内容区域，用默认插槽；如果组件里有多个语义明确的位置（比如头部、底部、图标），用具名插槽。作用域插槽则用于需要组件内部数据参与渲染的场景，典型的例子是表格组件的自定义列。通过作用域插槽，组件把当前行数据传出去，由父组件决定怎么渲染单元格，这样组件本身就不用关心单元格的复杂结构。

不过插槽不是越多越好。插槽越多，组件内部的状态暴露得越多，父组件的控制力越强，但组件的封装度会下降。所以插槽设计要在“灵活”和“省心”之间找平衡。我通常只给那些确实需要个性化扩展的地方开放插槽，其他位置保持一致。

2.4 边界情况：属性透传、inheritAttrs 与 $attrs

这里有个细节，很多新手会忽略。Vue 组件上写原生属性（比如class、style、id、>