企业官网建设流程全解析

Vue3的组件通信，说简单也简单，说复杂是真的复杂。以前带着新人做后台管理系统时，我见过太多人把props和emit背得滚瓜烂熟，结果一遇到跨层级传值、兄弟组件同步这种场景就原地懵圈。也有人学了Pinia之后，恨不得所有数据都往store里塞，最后调试的时候打开Vue Devtools一看，一片汪洋，根本分不清哪个状态是哪个页面在用。

这节Vue3组件通信的内容，我结合自己实际项目的踩坑经验，把这几种通信方式的原理、适用边界、常见误区和实用技巧一次性理清楚。不管你是刚学完Vue3基础、在面试前突击组件通信的开发者，还是在真实项目中越写越乱、想找个靠谱方案的同行，这篇文章都值得你花时间读完。我不打算只给你背代码，而是把"为什么这个场景要用这种方式"讲透，因为这才是组件通信真正的分水岭。

1. 通信方案取舍：Vue3真正考验人的是"该用哪个"

我以前在公司经常问来面试的人一个问题："你们项目里组件通信都用什么？"十有八九会回答"props、emit、vuex"。这个答案不能算错，但它暴露了一个很典型的问题：很多开发者只是机械地记住了API，脑子里根本没有"场景-方案"的映射关系。

Vue3的组件通信方式比Vue2多了不少，再加上<script setup>语法糖的普及，很多老写法已经变了。我根据实际项目经验，先给出一张总览表，把主流的通信方式按适用场景分个类，后面再逐个展开讲。

看到这张表，你可能会说："这不就是把官方文档的推荐抄了一遍吗？"别急，真正的干货在后面的原理分析和踩坑记录里。比如props那一节，我会讲一个我线上项目遇到过的响应式丢失问题；provide/inject那一节，会有一个让很多新手百思不得其解的"数据变成死值"的经典案例；mitt那节，我会聊聊为什么官方都推荐了Pinia，我还在某些场景坚持用事件总线。

方案本身没有绝对的好坏，只有适不适合当前的组件结构和数据流。接下来我按"从最近到最远"的通信距离来展开，父子关系先讲，跨层级和全局通信放后面。

2. 父传子：props的正确姿势与那条不能碰的红线

2.1 从defineProps类型声明说起

在<script setup>里，父传子最标准的写法是defineProps。很多新手会看到一个很困惑的点：为什么有时候defineProps()要接收一个数组或对象，有时候却只调用一个空函数？我直接给出现阶段最推荐的写法——类型声明。

<!-- Child.vue --> <script setup lang="ts"> interface UserInfo { name: string age: number tags?: string[] } const props = defineProps<{ title: string userInfo: UserInfo count?: number }>() </script> <template> <div> <h2>{{ props.title }}</h2> <p>{{ props.userInfo.name }}</p> </div> </template>

这里有个很多刚上手TS的人容易踩的坑：在模板里直接用title没问题，但在<script setup>内部用，必须写成props.title，因为defineProps的返回值才是那个响应式props对象。如果直接在script里写console.log(title)，会直接报未定义。

2.2 解构props会丢失响应性

这是我在真实项目里犯过的错，也是面试时高频出现的考点。在Vue3里，像下面这样直接解构props，在Vue 3.5之前的版本中，解构出来的变量会丢失响应性。

<script setup lang="ts"> const { title, count } = defineProps<{ title: string count: number }>() // 在子组件中对count进行watch，当父组件更新count时 // 这个watch可能不会触发（Vue 3.5之前） watch(count, (newVal) => { console.log('count updated:', newVal) }) </script>

在Vue 3.5之前，正确的做法是使用toRefs或者直接用props.xx。Vue 3.5之后，官方支持了props解构的响应式转换，但为了兼容性和可读性，我在项目中依然倾向于保持props.xxx的写法，只在模板里直接用短变量名。这个习惯让代码在版本升级时少了很多麻烦。

2.3 单向数据流的红线为什么碰不得

props是只读的，子组件不能直接修改props的值。这条规则几乎所有教程都会讲，但很少有人说清楚为什么。我用一个真实的例子来说明：

• 父组件持有一个userList数据，传给子组件去做列表展示。
• 如果子组件直接props.userList.push(newItem)，看起来挺好，父组件的userList也会同步变化，因为引用是同一个。
• 过几天需求变了，列表页面要展示两种筛选条件。父组件在另外一处逻辑里基于旧的userList做了个统计，结果因为子组件偷偷改了数组，统计数据莫名其妙地变了。

这种"任何组件都能随手改共享数据"的写法，短期看着方便，长期就是噩梦。数据流在哪个环节被改了你根本不知道，排查问题时只能逐个组件去找。所以正确的姿势永远是：子组件通过emit发事件，让父组件自己去改，数据源始终只有一个Owner。

<!-- 正确做法：子组件通知父组件去修改 --> const emit = defineEmits<{ (e: 'update:userList', newList: UserInfo[]): void }>() function handleAddTag(tag: string) { const newList = props.userList.map(item => ({ ...item, tags: [...(item.tags || []), tag] })) emit('update:userList', newList) }

也许你会问："那我用对象引用传递，改的是内部的某个属性，props的引用没变，这算不算违反单向数据流？"严格来说，这依然会带来数据流混乱的问题。如果你确实需要父子组件共享一个可变对象，优先考虑这个对象是否应该提升到父组件，或者直接考虑Pinia。等到代码里出现三四个层级都在改同一个对象时，你就知道这个原则有多救命了。

3. 子传父：emits的命名陷阱与类型推导

3.1 defineEmits让事件名称和载荷都有约束

子组件向父组件通信，最标准的方式就是defineEmits。在Vue3 + TS的组合下，事件名称和载荷类型都可以被严格约束。我推荐所有项目都采用类型声明的方式：

<!-- Child.vue --> <script setup lang="ts"> const emit = defineEmits<{ (e: 'submit', payload: { name: string; age: number }): void (e: 'cancel'): void }>() function handleSubmit() { emit('submit', { name: 'Tom', age: 18 }) } </script>

这样写的好处是显而易见的：在你的组件里调用emit时，Volar会提示你事件名称只能从'submit' | 'cancel'里选，载荷类型也会校验。团队成员用错事件名，编译期直接报错，不用等运行时玄学报错。

3.2 kebab-case和camelCase那点破事

Vue3官方文档建议事件名用kebab-case，但实际开发中，我在TS类型里更推荐camelCase，因为类型字符串里写camelCase更自然。模板里监听可以用@submit，也可以写成@on-submit，两种都可以工作，但要注意名字的一致性。更关键的是，事件命名需要避开原生DOM事件名。

我有一个线上项目曾经出过这样的问题：子组件里定义了一个emit('click', data)，父组件写@click="handleChildClick"。看起来运行正常，但当这个子组件在某个父页面里和其他原生@click混在一起时，就非常容易造成混淆——事件到底是从子组件发射的，还是原生DOM的click？后来我强制团队规范：自定义事件统一用业务前缀，比如@user-click、@item-remove。这个规范看起来死板，但排查跨组件事件时，能省下大量时间。

3.3 紧记$event到底是什么

很多新手会在父组件监听时对$event产生疑惑。"$event到底是事件对象，还是emit出来的数据？"我直接给结论：

• 如果是原生DOM事件监听，比如@click="$event"，$event是原生事件对象。
• 如果是子组件的自定义事件，比如子组件emit('submit', payload)，父组件@submit="handleSubmit"，那么handleSubmit的第一个参数就是payload，跟DOM的Event对象没有任何关系。

如果有两个自定义事件的载荷都要传入同一个处理函数，那就别用内联$event了，直接写箭头函数：

<template> <Child @submit="(payload) => handleSubmit('from-child', payload)" /> </template>

这个基础和细节很多人不注意，但面试官很喜欢拿它出题。

4. v-model：双绑也可以一个组件玩出花

4.1 v-model的本质是语法糖

很多Vue开发者都用过v-model做表单双向绑定，但少有人意识到，Vue3的v-model其实是:modelValue加上@update:modelValue的语法糖。

<!-- 父组件写法 --> <Child v-model="searchText" /> <!-- 等价于 --> <Child :modelValue="searchText" @update:modelValue="searchText = $event" />

子组件内部的实现也很简单：

<!-- Child.vue --> <script setup lang="ts"> const props = defineProps<{ modelValue: string }>() const emit = defineEmits<{ (e: 'update:modelValue', value: string): void }>() function handleInput(event: Event) { const value = (event.target as HTMLInputElement).value emit('update:modelValue', value) } </script>

理解了这一点，你就能明白为什么组件里自定义v-model的时候约定俗成要用modelValue这个字段名。

4.2 多个v-model和参数化v-model

Vue3支持在一个组件上使用多个v-model，还能给它们各自命名，这让很多老Vue2开发者很不适应，但用熟了之后发现是真的香。比如一个筛选组件，需要同时管理关键词、分类、排序三个状态，按老写法可能要把组件拆成三个或者传一个复杂对象，但现在可以这样：

<!-- 父组件 --> <FilterPanel v-model:keyword="keyword" v-model:category="category" v-model:sort="sortOrder" />

这比v-model加一坨props和emits清爽得多。子组件里的定义方式就是props和emits各写一组：

<script setup lang="ts"> defineProps<{ keyword: string category: string sort: 'asc' | 'desc' }>() const emit = defineEmits<{ (e: 'update:keyword', value: string): void (e: 'update:category', value: string): void (e: 'update:sort', value: 'asc' | 'desc'): void }>() </script>

4.3 v-model搭配computed实现"局部改写，全局同步"

有时候子组件拿到的v-model数据需要做一次加工再展示，但还是要写回父组件。比如一个带单位的价格输入框，用户输入"123"，子组件要显示"123元"，但v-model绑定的值应该是纯数字123，这个场景可以用computed加setter优雅实现：

<script setup lang="ts"> const props = defineProps<{ modelValue: number }>() const emit = defineEmits<{ (e: 'update:modelValue', value: number): void }>() const displayValue = computed({ get() { return `${props.modelValue}元` }, set(val: string) { const num = parseFloat(val.replace('元', '')) if (!isNaN(num)) { emit('update:modelValue', num) } } }) </script>

这个模式的精髓在于：子组件内部可以自由地"加工"输入输出的数据，而对外仍然保持标准的v-model接口，调用方完全感知不到内部实现的变化。这种封装能力，在表格组件、表单控件类组件开发中特别常用。

5. ref加defineExpose：什么时候该把子组件内部直接掏出来

5.1 获取子组件实例的正确姿势

v-model解决了数据同步，但有些场景你需要直接调用子组件内部的方法。最典型的就是"表单提交校验"：父组件点提交，需要让子表单组件先做一次校验，如果通过才提交。

在Vue3的<script setup>中，子组件默认是"闭合"的，外部拿不到内部定义的方法和属性。这时候必须用defineExpose显式暴露：

<!-- FormChild.vue --> <script setup lang="ts"> function validate(): boolean { // 校验逻辑 return true } defineExpose({ validate }) </script>

父组件里就用模板ref去拿子组件实例：

<template> <FormChild ref="formRef" /> </template> <script setup lang="ts"> import { ref } from 'vue' const formRef = ref<InstanceType<typeof FormChild> | null>(null) function handleSubmit() { if (formRef.value?.validate()) { // 提交 } } </script>

5.2 一个关于onMounted的经典坑

很多新手拿到ref后，在父组件的onMounted里立刻去调用子组件的方法，结果发现拿不到。原因是：父组件的onMounted触发在子组件的onMounted之后，但这不代表子组件的实例和方法就一定可用。如果你在父组件的setup同步代码中直接访问formRef.value，那必然是null，因为子组件还没挂载。

正确的方式是在异步时机里访问，比如onMounted、事件回调、nextTick之后：

import { onMounted, nextTick, ref } from 'vue' onMounted(async () => { await nextTick() formRef.value?.validate() })

5.3 defineExpose的使用边界：别把子组件变成无底洞

这个方案的便利性也不该被滥用。如果一个父组件经常需要直接操作子组件的内部方法，那你要反思：你们的组件边界是否划分合理？组件应该是自治的，外部通过事件或props来协作，而不是像操作一个对象一样从外面随意调用它的内部逻辑。

我自己的项目中，defineExpose主要用于两类场景：

• 表单类组件的校验或重置方法
• 需要精确控制DOM行为的组件，比如图表组件暴露resize方法、滚动容器暴露scrollToTop

如果代码里出现了大量的xxxRef.value.xxx()，我的第一反应是检查组件设计是不是出了问题，而不是继续往这个洞里加方法。尽量减少这种"穿透式"调用，会让组件的独立性高很多，重构时也能少花时间。

6. provide和inject：跨层级通信的响应式大坑

6.1 provide/inject的定位：自上而下的共享通道

遇到祖先组件需要给深层孙组件传数据，你可能会本能地想：props一层层传呗。但层级一旦超过三层，这种透传就是灾难：中间层组件明明不需要这个数据，却得在props里声明一遍，只为了把它往下递。这时provide/inject的好处就出来了。

// App.vue（祖先组件） <script setup lang="ts"> import { provide, ref } from 'vue' const theme = ref<'light' | 'dark'>('light') provide('theme', theme) </script>

<!-- 任意深层子组件 --> <script setup lang="ts"> import { inject } from 'vue' const theme = inject<Ref<'light' | 'dark'>>('theme') </script>

6.2 非响应式的inject：最经典的"死值"问题

我见过太多项目里的这个坑：开发者在祖先组件里provide('userInfo', userInfo)，结果userInfo是一个普通对象。等用户信息更新后，孙组件里怎么都不刷新。

原因很简单：provide只能保证"传入的值能拿到"，但它不会自动帮你把值变成响应式。如果传入的是普通对象，它就只是一个静态快照。正确做法是：

import { provide, ref } from 'vue' const userInfo = ref({ name: 'Tom', age: 18 }) provide('userInfo', userInfo)

孙组件里要么用inject配合computed去派生，要么严格遵守"通过方法修改"的约定：

// 同层或祖先组件中提供修改函数 function updateUserName(name: string) { userInfo.value.name = name } provide('updateUserName', updateUserName)

6.3 关于修改权限：inject进来的数据别直接改

我在代码审查里经常看到一些人直接在孙组件里写userInfo.value.name = 'Jerry'，然后还振振有词："反正inject拿到的是ref，改一下就能同步到祖先了。"

这种写法有个很严重的问题：数据的变更来源会变得不可追踪。如果十个组件都能修改userInfo，改到后面你根本不知道是哪个组件改的、什么时候改的。

我的实践经验是：provide时，响应式数据和修改方法成对提供。数据由提供者统一管理，消费者只能通过方法去修改。如果需要，也可以用readonly包裹一层，防止被直接改写：

import { provide, readonly, ref } from 'vue' const userInfo = ref({ name: 'Tom' }) function setUserName(name: string) { userInfo.value.name = name } provide('userInfo', readonly(userInfo)) provide('setUserName', setUserName)

这样既保证了跨层级传值的便利，又守住了数据流的统一出口。站在维护者的角度看，十个组件里只有一个能改数据，调试成本会从"大海捞针"降级到"顺藤摸瓜"。

6.4 别把provide/inject当成免费的全局状态管理

provide/inject虽然好用，但它不是为跨路由、跨页面的大范围共享设计的。它最合适的场景是一个组件子树内部的服务供给：

• 某个页面容器给它的多个子组件提供用户信息
• 某个布局组件给内部的导航、侧边栏提供菜单展开状态
• 提供全局的主题、语言配置

如果你发现provide的数据需要跨路由、跨多个完全不相关的页面共享，那它就不是provide的职责了。直接上Pinia吧，别硬撑。

7. mitt事件总线：被误解但偶尔真香的方案

7.1 Vue3里为什么事件总线"过气"了

Vue2时代有一个很流行的通信方式：$on、$off、$emit做全局事件总线。到了Vue3，官方移除了实例上的$on和$off，社区推荐的替代方案是 mitt ——一个只有200多字节的小库。

Pinia出现之后，事件总线被很多人鄙视，说它会导致状态混乱。这个批评有道理，但要分场景。事件总线最大的问题是没有"状态"的概念，谁发射了事件、谁监听了事件，都是隐式的。如果项目里大量使用事件总线传数据，简直是在给自己埋雷。

7.2 我还在用mitt的两个真实场景

话虽如此，我维护的一个中后台项目里依然在使用mitt，而且效果很不错。场景是这样的：

第一个场景是表头和表格内容组件之间的联动。我们的表格组件拆成了头部（包含排序、筛选）和内容区两部分，它们不是父子关系，但需要非常频繁地通信：点击表头排序，内容区要触发重排；内容区滚动到特定位置，表头要同步高亮。用Pinia来管理这种高度时序性的UI协作就很别扭，因为根本不需要持久化状态，只要当下触发一次就好。mitt一发一收，干净利落。

第二个场景是权限更新后通知全页面刷新用户菜单。用户重新登录或切换角色后，整个页面布局都要刷新菜单。如果用Pinia，我得改状态、等watch触发，绕一大圈。用mitt直接触发一个refresh-menu事件，布局组件监听后重新拉取菜单，简单粗暴。

// mitt.ts import mitt from 'mitt' type Events = { 'refresh-menu': void 'sort-change': { key: string; direction: 'asc' | 'desc' } } const emitter = mitt<Events>() export default emitter

7.3 用mitt一定要记得off

用事件总线最怕的就是内存泄漏和重复监听。组件卸载的时候，如果不off掉监听，回调会残留在总线里。特别是SPA应用，组件反复挂载和卸载，监听器越积越多，事件触发时多个已销毁组件还会各自执行一遍逻辑，这是很糟糕的体验。

我的习惯是在组件中这样写：

import { onMounted, onUnmounted } from 'vue' import emitter from '@/utils/mitt' function handleMenuRefresh() { // 处理逻辑 } onMounted(() => { emitter.on('refresh-menu', handleMenuRefresh) }) onUnmounted(() => { emitter.off('refresh-menu', handleMenuRefresh) })

再给个更稳的建议：在mitt封装里统一管理事件名，避免字符串魔法值散落在代码里。我们上面用了type Events定义，这样IDE能自动补全事件名，传参也有类型校验，算是弥补了事件总线最大的短板。

7.4 事件总线 vs provide/inject vs Pinia的抉择

有一些经验可以分享：

• 需要跨层级但只在一棵组件子树内共享状态：优先provide/inject。
• 需要跨路由、跨页面共享持久状态：直接Pinia。
• 临时性的UI交互提醒、非状态类的业务信号：可以考虑mitt。
• 两者都行，但拿不准时：优先Pinia，因为它有DevTools的time-travel调试，排障优势太明显了。

8. Pinia兜底：共享状态的最终归宿不是无脑塞

8.1 storeToRefs解决响应式丢失

Pinia现在已经是Vue3官方推荐的全局状态管理库。但很多从Vue2的Vuex转过来的人，会写出一堆低级错误。最典型的就是解构store之后发现状态不响应了：

import { useUserStore } from '@/stores/user' const userStore = useUserStore() // 这样解构出来的userInfo不具备响应性 const { userInfo } = userStore

正确姿势是用storeToRefs：

import { storeToRefs } from 'pinia' const userStore = useUserStore() const { userInfo } = storeToRefs(userStore)

可以这样理解：Pinia的store本身是用reactive包装的，它解构之后和普通响应式对象解构遇到的问题是一模一样的。storeToRefs就是专门为它打造的"响应式解构工具"。

8.2 别把store当成万能储物间

比起这种API层面的小坑，我更想重点说说一个架构层面的大坑：把不该放进store的数据全塞进去。

我见过不少项目的store里全是各种组件内部临时状态，比如弹窗的显隐、某个表格的当前筛选条件、某个表单的草稿。这些状态只属于特定的组件子树，放到store里除了让store越变越大、越来越难维护之外，没有任何好处。每次打开DevTools，看到store里几百个字段，查一个问题得翻半天。

我的建议是：

• 只在多个不相关组件（尤其是跨路由、跨页面）需要共享时才放store。
• 单个组件内部的临时状态，保持在组件内部就好。
• 某个组件子树内部的共享状态，优先用provide/inject。
• 粒度上，一个业务模块建一个store，不要搞一个巨大的root store包罗万象。

8.3 Pinia的性能考量

还有一点可能被忽略：store的state是全局响应式的，任何组件访问它都会建立依赖追踪。如果某个store特别大、字段特别多，而组件频繁地修改其中的值，会连带触发大量组件的重新渲染。

在业务中，我会把store拆分成多个更小的store，并且避免让一个组件同时依赖太多store。比如用户信息、权限、购物车、消息通知，各自独立。这样数据流清晰，修改一个store时，颗粒度也更小，渲染性能也更能把控。

把store的边界画清楚，比花时间去调什么"响应式性能优化"有意义得多。对于大多数中后台系统来说，组件的更新范围控制住了，性能问题就解决了一大半。

9. 实际项目中我是怎么选的

最后分享一个我在带团队时惯用的决策流程，也算是我这几年写Vue3组件通信的一个经验沉淀。拿到一个通信需求，我通常会连续问自己四个问题：

1. 这两个组件是父子关系吗？是，优先props + emits。
2. 需要双向同步吗？是，把v-model用起来，别手动绑一坨props和事件。
3. 数据需要跨很多层级传递吗？是，看看是否限定在一个页面/模块内部，是就provide/inject，涉及跨路由就上Pinia。
4. 只是临时通知一下，不需要持久状态吗？是，这时候才考虑mitt。

这套流程看着简单，但坚持下来之后，项目的代码结构会变得非常干净。数据流的修改源头永远清晰可查，组件边界也稳。

多说一句关于面试的。组件通信几乎是Vue3面试必考题，但面试官真正想听到的绝不是你会背几个API。他更想确认的是：你知不知道props是只读的、为什么，你知不知道v-model的本质是语法糖，遇到跨层级通信时你的权衡思路是什么。一个能把"为什么"讲清楚的人，才真的算把Vue3熟练掌握了。

我自己刚学Vue3时也被这些通信方式搞昏头过，后来带的几个新人更是踩了一轮又一轮的坑。希望这一节的内容能让你少走这些弯路。Vue3魔法手册的组件通信篇就到这里，下一节我们继续聊别的玩法。