企业官网建设流程全解析

1. props下行与emits上行：父子通信这条主线为什么这么设计

组件通信这个话题，几乎所有Vue3面试题里都会出现，但很多人背了一堆答案，真到项目里却用不对。Vue3的组件通信本质上解决一个问题：多个组件之间如何共享状态、如何通知变化。而父子通信这条线，是整个通信体系的基石，也是最容易被理解偏的地方。

1.1 单向数据流不是限制，是保护机制

先看一个最典型的场景：

<!-- 父组件 --> <template> <Child :count="count" @increment="handleIncrement" /> </template> <script setup> import { ref } from 'vue' import Child from './Child.vue' const count = ref(0) const handleIncrement = () => { count.value++ } </script>

<!-- 子组件 --> <template> <div> <p>当前计数：{{ count }}</p> <button @click="$emit('increment')">增加</button> </div> </template> <script setup> const props = defineProps({ count: { type: Number, default: 0 } }) const emit = defineEmits(['increment']) </script>

很多新手会问：子组件里直接改props.count不行吗？ Vue在开发模式下会直接抛警告，告诉你不允许修改prop。这不是Vue故意为难你，而是因为props是引用类型时，如果子组件改了值，父组件的状态也会跟着变，但父组件完全不知道是谁改的、什么时候改的、为什么改的。当组件复杂到一定程度，这种"暗改"会让状态完全不可追踪。

单向数据流的本质是状态变更的可追溯性——官方文档里"单向数据流"这几个字看着简单，实际含义是：数据只能从父向子流动，子组件要改变数据，必须通过事件通知父组件，由父组件来决定改还是不改。这样所有的状态变化都集中在父组件这里，排查问题的时候思路非常清晰。

1.2 defineProps和defineEmits在script setup里的类型安全感

Vue3进入<script setup>时代之后，defineProps和defineEmits有了很大变化。它们不再是需要import的API，而是编译器宏，直接调用即可。更重要的是，可以结合TypeScript做精细的类型约束：

<script setup lang="ts"> interface Props { title: string count?: number tags: string[] onUpdate?: (val: number) => void } const props = defineProps<Props>() // 或者需要默认值时 const props = withDefaults(defineProps<Props>(), { count: 0, tags: () => [] }) const emit = defineEmits<{ (e: 'update:count', value: number): void (e: 'change', payload: { id: number, name: string }): void }>() </script>

这比Vue2时代每个prop都要手写type: Object, default: () => ({})要舒服太多。写完父组件传值的时候，IDE就能提示props的类型。子组件事件声明的类型也会传递到父组件的监听事件上，类型不匹配直接标红，不用等到运行时报错才发现参数传反了。

这里要提醒一个细节：withDefaults里引用类型的默认值必须用工厂函数，也就是写() => []而不是[]。这和Vue2里的default: () => []是一个原理，为了防止多个组件实例共享同一个引用导致数据串了。

2. defineModel与v-model：表单类组件最顺手的通信姿势

父子通信除了props/emits，还有一条更符合表单直觉的路：v-model。Vue3里v-model升级了，defineModel这个宏让表单类组件的双向绑定变得极其简洁。

2.1 传统modelValue绑定的写法与局限

Vue2里，组件上的v-model默认绑定value，触发input事件。Vue3改成了modelValue加update:modelValue。手动实现一个输入框组件：

<template> <input :value="modelValue" @input="$emit('update:modelValue', $event.target.value)" /> </template> <script setup> defineProps(['modelValue']) defineEmits(['update:modelValue']) </script>

父组件里：

<MyInput v-model="username" />

等价于：

<MyInput :modelValue="username" @update:modelValue="username = $event" />

这种写法维护起来很累，尤其是组件里如果有多个需要双向绑定的值，每个都要写modelValue: xxx加update:modelValue: xxx，模板里还得手动绑定$event.target.value，代码量不小。

2.2 defineModel宏：绑定逻辑直接收进子组件

Vue 3.4之后defineModel正式转正，原来的样板代码可以直接收敛：

<template> <input v-model="val" /> </template> <script setup> const val = defineModel() </script>

就这么三行。defineModel()返回的是一个ref，这个ref的值对应父组件传来的modelValue。在子组件里对val赋值，会自动触发update:modelValue事件通知父组件更新。模板里直接v-model="val"，根本不需要手动监听input事件再emit。

多个双向绑定的场景也舒服：

<!-- 搜索表单组件 --> <script setup> const keyword = defineModel('keyword') const pageSize = defineModel('pageSize', { default: 10 }) </script>

父组件：

<SearchForm v-model:keyword="searchForm.keyword" v-model:pageSize="searchForm.pageSize" />

这样写就跟操作普通ref一样，不用感觉到"通信"的存在。编程体验和直接使用ref没有差异，这就是好的封装应该有的效果。老项目如果用Vue 3.4之前的版本，可以用@vueuse/core的useVModel达到类似效果，原理就是手动做一层getter/setter的代理。

2.3 defineModel的约束：它还是单向数据流

需要注意：defineModel看起来像"双向绑定"，但本质上依然是props下行、emits上行。Vue在背后做的事情是：

const modelValue = ref(props.modelValue) watch(modelValue, (val) => { // 仅当值非通过外界修改时触发事件 })

所以子组件里对val赋值，其实执行的是emit('update:modelValue', newVal)，由父组件去改真正的数据。永远不要在defineModel返回的ref上做复杂的状态派生，不要在watch里又改这个ref的值，很容易形成循环更新。我之前在一个搜索组件里做过类似的事情，watch keyword变化然后自动补全，再回写keyword，结果DevTools里不断闪烁，排查了半天才发现是自激循环。

3. ref与expose：如何把组件内部能力安全地交出去

通信不只是传数据，还有一种场景：父组件要主动调用子组件里的某个方法，比如表单组件里的validate、弹窗组件里的open。Vue3里通过ref拿到组件实例，配合defineExpose把内部方法暴露出去。

3.1 父组件获取子组件实例的两种方式

<!-- 子组件 FormModal.vue --> <template> <dialog v-if="visible"> <slot /> </dialog> </template> <script setup> import { ref } from 'vue' const visible = ref(false) const open = () => { visible.value = true } const close = () => { visible.value = false } defineExpose({ open, close, visible }) </script>

<!-- 父组件 --> <template> <FormModal ref="modalRef" /> <button @click="openModal">打开弹窗</button> </template> <script setup> import { ref } from 'vue' import FormModal from './FormModal.vue' const modalRef = ref() const openModal = () => { modalRef.value?.open() } </script>

ref在组件上的行为和普通DOM元素不同，它拿到的是组件暴露出来的对象。在<script setup>里，组件内部的所有绑定默认是关闭的，父组件通过ref只能访问到defineExpose显式暴露的内容。这是Vue3和Vue2很大的一个区别——Vue2里this.$refs.child能访问到子组件所有data和方法，Vue3默认不暴露。这个设计是刻意的：组件边界越明确，重构成本越低。

3.2 什么时候该用expose而不是props

我见过不少团队把visible这个状态直接通过props传给弹窗组件，父组件管visible.sync，子组件里又emitupdate:visible，绕来绕去，代码可读性很差。当然这也是一种写法，但只要弹窗的打开逻辑稍有变化，比如打开时需要重置表单、拉取详情数据，父组件就得写一堆监听逻辑。

更合理的做法是：状态归子组件，方法暴露给父组件。父组件不需要关心弹窗内部何时渲染、如何渲染，只需要open()或者close()。这是"命令式调用"和"声明式渲染"两种思维模式的区别。命令式更适合临时性的UI行为（弹窗、抽屉、消息提示），声明式更适合状态型数据展示。

3.3 expose的坑：响应式丢失

defineExpose暴露出去的对象，如果是reactive的ref，父组件拿到之后修改它，是不会触发子组件更新的。比如上面例子里的visible，我暴露的是ref本身，父组件如果做modalRef.value.visible = false，子组件里visible.value确实变了，但因为是ref，子组件的模板用了visible，在模板里是自动解包的，会响应。但如果你暴露的是一个reactive对象里的普通属性，那就有问题了：

const state = reactive({ visible: false }) defineExpose({ state })

父组件改modalRef.value.state.visible = false，子组件模板里的state.visible可以直接感知变化，因为整个state的代理还活着。但如果暴露的是一个原始值：

let visible = ref(false) defineExpose({ visible: visible.value })

这种情况下，父组件拿到的就是一个静态的false，怎么改都没有反应，因为ref的.value被提取出来之后，就和内部状态脱钩了。经验法则：通过expose暴露的状态，要么暴露整个ref/reactive对象，要么只暴露方法，不要提取原始值再去改。

4. provide/inject：跨层级通信的正确姿势与响应性陷阱

组件层级深了之后，父子通信越来越不方便。A组件嵌套了B，B嵌套了C，C需要A的数据，如果全走props一层层传，中间组件B就成了"数据搬运工"，这种模式有个专门的称呼叫prop drilling。provide/inject就是为了解决这个痛点。

4.1 provide/inject解决逐层透传

<!-- 根组件 --> <script setup> import { computed, ref, provide } from 'vue' import Child from './Child.vue' const userInfo = ref({ name: '张三', role: 'admin' }) const updateRole = (role) => { userInfo.value.role = role } provide('userInfo', userInfo) provide('updateRole', updateRole) </script>

<!-- 深层子组件 --> <script setup> import { inject } from 'vue' const userInfo = inject('userInfo') const updateRole = inject('updateRole') </script>

这样无论中间隔了多少层组件，最深层的组件都能直接拿到数据和修改方法。中间组件的props减少，职责也更清晰。

4.2 provide/inject的响应性陷阱

需要注意的一点：provide提供的内容默认不是自动响应式的。如果你写：

provide('count', count.value)

那inject拿到的是一个静态值，count变化之后，inject方不会更新。正确的写法是：

provide('count', count) // 直接提供ref，不要解包

或

provide('count', computed(() => count.value * 2))

inject方拿到的就是ref，模板里自动解包，脚本里需要.value。这个坑很多人踩，尤其是从Vue2 Option API迁移过来的开发者，Vue2里provide是data对象直接提供，响应式还在（理论上），Vue3改成了实例对象的形式，很多人不习惯加ref包裹。

4.3 用symbol做注入key避免命名冲突

大型项目里，provide/inject的key如果都用字符串，不同模块之间很可能冲突。比如两个独立的业务组件都用'theme'作为key，后provide的就会覆盖先provide的，排查起来非常痛苦。更好的做法是用Symbol：

// 单独的文件 symbols.js export const THEME_KEY = Symbol('theme') export const USER_KEY = Symbol('user')

import { THEME_KEY } from './symbols' provide(THEME_KEY, theme) inject(THEME_KEY)

Symbol保证唯一性，还能带上语义化的描述。也可以把key定义成一个函数式变量，甚至提供类型：

import type { InjectionKey } from 'vue' interface UserInfo { name: string role: string } const userKey: InjectionKey<UserInfo> = Symbol('user') provide(userKey, userInfo) inject(userKey)

这样inject出来的数据有完整的类型推断，写起来体验提升一个档次。

4.4 与组合式函数搭配的provide/inject

provide/inject真正强大之处在于和组合式函数结合。你可以把一个复杂功能的全部状态和操作封装在一个use函数里，然后在顶层组件provide出去，任何子组件都能inject到整个能力集合。

// useTheme.js import { computed, ref } from 'vue' export function useThemeProvide() { const theme = ref('light') const toggleTheme = () => { theme.value = theme.value === 'light' ? 'dark' : 'light' } const isDark = computed(() => theme.value === 'dark') return { theme, isDark, toggleTheme } } // 顶层组件 const themeStore = useThemeProvide() provide('themeStore', themeStore) // 任意子组件 const themeStore = inject('themeStore')

这个模式下，复杂业务的状态管理可以完全脱离逐层传prop。但要注意，inject最好在setup顶层调用，不要在循环、条件分支里调用，否则会拿到undefined。

5. 兄弟组件通信：mitt事件总线与Pinia的适用边界

同一个父组件下的两个兄弟组件，A的数据变了，B要感知到。props/emits直接通信需要借助父组件中转，代码很啰嗦。很多项目直接跳到了全局状态管理的方案，但其实这里有两种选择：轻量的事件总线（mitt）和完整的全局状态库（Pinia）。

5.1 mitt：小而快的事件发布订阅

Vue3官方移除$on/$off之后，社区里最常用的事件总线库是mitt。它的使用方式很简单：

// utils/eventBus.js import mitt from 'mitt' export const eventBus = mitt()

// A组件：发布 import { eventBus } from '@/utils/eventBus' eventBus.emit('refresh-list', { page: 1 }) // B组件：订阅 import { eventBus } from '@/utils/eventBus' import { onUnmounted } from 'vue' const handler = (payload) => { console.log('收到刷新通知', payload) } eventBus.on('refresh-list', handler) onUnmounted(() => { eventBus.off('refresh-list', handler) })

mitt只有200多字节，比Vue2自带的EventBus还轻，而且支持通配符*监听所有事件。核心API就四个：on、off、emit、all（事件管理器）。

5.2 事件命名的规范与排查成本

mitt用起来方便，但有个致命的问题：事件名是字符串，没有类型约束，事件谁发的、谁在监听、参数结构是什么，全靠代码注释和自觉。项目规模一大，一个新的维护者面对几十个事件命名，根本不知道某个事件会影响哪些组件。我见过一个项目里两个模块都用了refresh这个事件名，后来第二个覆盖了第一个的监听，线上数据一直刷新不出来，排查了很久。

所以如果要用mitt，建议至少做到两点：

• 事件名统一加模块前缀，比如tab:active-changed、cart:item-removed，比裸用active、remove清晰很多。
• 单独建一个events.ts文件集中维护事件名常量，避免手写字符串散落各处，至少保证改名的时候全局能搜到。

5.3 Pinia：需要"状态"而不是"通知"时的正确选择

事件总线适合"通知一声"的场景——你通知别人发生了一件事，不需要关心谁会响应。但如果多个组件要共享同一份数据，并且这份数据的变更会影响多个视图，那就是状态共享的问题，这时候状态管理库比事件总线更合适。Pinia在Vue3项目里几乎是标配：

// stores/cart.js import { defineStore } from 'pinia' import { ref, computed } from 'vue' export const useCartStore = defineStore('cart', () => { const items = ref([]) const totalPrice = computed(() => items.value.reduce((sum, item) => sum + item.price * item.qty, 0) ) const addItem = (item) => { items.value.push(item) } const removeItem = (id) => { items.value = items.value.filter(item => item.id !== id) } return { items, totalPrice, addItem, removeItem } })

<!-- 任意组件 --> <script setup> import { useCartStore } from '@/stores/cart' import { storeToRefs } from 'pinia' const cartStore = useCartStore() const { items, totalPrice } = storeToRefs(cartStore) const handleAdd = () => { cartStore.addItem({ id: Date.now(), price: 99, qty: 1 }) } </script>

这里有个常见的坑：直接从store里解构state会丢失响应性，必须用storeToRefs包一层才能解构。方法函数直接解构没问题，因为它本来就绑定在store上下文上。

5.4 事件总线与Pinia如何抉择

判断标准其实很简单：

• 只是"通知"性质的通信，比如刷新列表、重置表单、清除缓存，用mitt，因为事件是一次性的、瞬时的。
• 多个页面组件共享数据，且数据是持久的、需要计算派生值的，用Pinia。
• 不确定的时候，默认选Pinia。事件总线用多了，项目里到处都是隐式的依赖关系，新人接手很难上手。

另外提一点：不要在同一份数据上混用事件总线和Pinia。比如先用Pinia存了一份数据，某个操作又通过mitt发了一个事件传了一份一模一样的副本，两个来源一旦不一致，调试起来就像破案。数据来源有且只有一个，其他组件要么用store，要么用事件通知，不要双写。

6. 组件通信的选型决策与实战避坑记录

前面几种方式单独用都不难，难的是在一个真实项目里，面对十几个组件、四五层嵌套结构，如何选择正确的通信方案。这里给一个我自己实际项目里验证过的决策思路，以及踩过的几个典型坑。

6.1 通信方式选型：从组件关系来判断

选型核心逻辑：先判断关系是父子、兄弟还是跨层级，再判断数据是瞬时通知还是持久状态，然后决定用哪种方案。

6.2 踩坑记录：props解构后响应式丢失

Vue3里defineProps返回的是reactive proxy，直接解构出来的是普通值：

const props = defineProps(['count']) const { count } = props // 响应式丢失，count是快照

但如果是模板里这样写就没有问题，因为模板会记住上下文。在<script setup>里直接用解构出来的count去渲染或计算，就会拿到初始值，后面父组件再怎么更新count，这里都不会变。

解决方式有三种：

• 模板里直接用props.count，不解构。
• 用toRefs包一层再解构。
• Vue 3.5之后支持在defineProps处自动解构，但需要显式开启。

我的建议是简单场景直接props.xxx，复杂场景用计算属性包裹。

6.3 踩坑记录：emits声明遗漏

在Vue3里，如果子组件emit了一个没有在defineEmits里声明的事件，开发模式下Vue会警告提示你多了一个未声明的事件。这个警告不影响运行，但一旦你开启了严格模式或者上了CI检查，就可能报警告。更重要的是，未声明的事件不会被父组件继承到组件的根节点上，如果父组件用@click监听子组件根DOM点击，而这个点击事件是从子组件内部emit出来的，你将收不到。

这是个比较隐蔽的问题。我用过一个封装好的按钮组件，内部点击后emit了一个custom-click，父组件监听的是@click，结果发现永远触发不了。排查了很久才发现，Vue3在组件上没有显式声明的事件，会被当作原生事件绑到组件的根DOM元素上，所以父组件的@click实际上可能绑到了根元素上，和组件内部emit的custom-click完全不是一回事。最终方案是在defineEmits里显式声明'click'。

6.4 踩坑记录：provide/inject在组件更新时拿不到最新值

动态组件场景下，一个组件inject了父级的某个响应式数据，但组件在依赖缓存时，inject的绑定可能会滞后。这个场景比较少见，我遇到的情况是这样的：父组件切换了用户角色，动态组件里的子组件通过inject获取角色数据，结果角色已经切换，子组件里的值还是旧的。

原因是provide的值如果是对象或ref，响应式传播正常情况下是没问题的，但如果provide的是一个组件实例上的普通属性，并且组件被KeepAlive缓存，那么子组件inject到的引用可能不会重新求值。解决办法：provide里始终提供ref或computed，不要直接提供普通值；keep-alive缓存组件尽量不要依赖父级动态注入的数据，改由Pinia管理更可靠。

6.5 一个小技巧：组合式函数里的通信复用

如果多个组件需要同样的通信逻辑，可以把这部分抽成一个组合式函数。比如列表页里常见的"筛选条件变化后刷新列表"：

// useListRefresh.js import { ref } from 'vue' import { eventBus } from '@/utils/eventBus' export function useListRefresh(listKey) { const listData = ref([]) const refresh = () => { // 重新请求列表逻辑 } eventBus.on(`${listKey}:refresh`, refresh) return { listData, refresh } }

页面里的搜索组件和列表组件都引用这个use函数，搜索组件发通知，列表组件刷新数据。这样通信逻辑不是散落在组件内部，而是集中在一个有名字的函数里，维护起来维度更高一层。实测下来，比每个组件里写一套mitt的on/off要清爽得多。

7. 从Vue2迁移到Vue3时的通信方式升级清单

最后说一个很现实的问题：很多团队不是新起项目用Vue3，而是从Vue2老项目迁移过来。通信方式的差异是迁移中改动量最大的一块，我梳理过一份清单，每次迁移都可以对着检查。

这个表里面的每一项迁移我都实际操作过。印象最深的是$listeners的合并，老项目里那种在子组件上同时监听多个原生事件并透传到内部元素的写法，在Vue3里要全部改写成v-bind="$attrs"放在正确的位置，否则事件绑定会全部失效。迁移过程中最忌讳的就是只改语法不改思路，把Vue2的EventBus模式原封不动搬到Vue3去用，从一开始就注定了维护噩梦。

实际上Vue3的通信体系比Vue2要清晰很多，核心思想就一句话：数据流向有方向，状态来源有归属，组件边界要明确。想明白了这三个维度，props/emits、v-model、defineExpose、provide/inject、mitt、Pinia这些方案用起来就不会再纠结，因为每种方案都有它存在的理由，强行套用一种模式反而是问题的根源。