Vue 组件通信怎么写：四种常用方式一次讲清

你把一个页面拆成好几个组件，父组件想把下面的列表数据传进去，子组件点了按钮又得把结果告诉父组件；层级一深，隔了两三层的组件要共享一份数据，直接传 props 能绕晕你。Vue 组件通信就是组件之间互相传数据、发事件的规则，核心有四种：props 父传子、$emit 子传父、provide/inject 跨层级、Pinia 统一管理状态。本文把这四种常用方式一次讲清，并配上可直接复制的代码，你照着套就能把组件之间的数据流向理顺。编程狮用这四种方式覆盖了绝大多数业务场景。

Vue 组件通信怎么写：四种常用方式一次讲清封面图

一、vue 组件通信到底解决什么问题

vue 组件通信，说的是组件之间如何交换数据。Vue 的组件是独立封装的，每个组件有自己的数据和视图，默认互相看不见。但真实页面里，组件必然要协作：列表组件要拿到接口数据，弹窗组件要告诉父组件"用户点确定了"，这些都需要一套通信规则。

把组件想象成公司里的部门。销售部要把订单数据交给财务部（父传子），财务部算完要把结果回报销售部（子传父），而全公司都要查同一份"本月目标"（跨层级共享）。如果没有规则，数据就会乱传、重复、难追溯。

四种方式对应四种典型距离。props 解决"上层往直接下层送数据"；$emit 解决"下层往直接上层回报事件"；provide/inject 解决"祖先跨多层直接给后代送，不必一层层透传"；Pinia 解决"多个不相邻组件共享同一份可变状态"。理解了这四种距离，选型就不再是拍脑袋。

如果还没搭好 Vue 的基础环境，建议先过一遍 Vue.js 基础教程，把单文件组件和响应式搞明白，回来理解通信会更顺。新手最容易犯的错，就是能用 props 的硬去用全局状态，导致数据来源混乱，后面排查问题像大海捞针。

二、props 父传子：把数据从上层往下送

props 是父组件向子组件传数据最标准的方式，只能单向流动：父改了传下去，子收到新值；子不能直接改 props（会报警告），这是 Vue 故意设计的"单向数据流"，避免数据被任意修改后找不到源头。

下面是一段可直接运行的父传子示例：

<!-- Parent.vue -->
<script setup>
import Child from './Child.vue'
const msg = '编程狮欢迎你'
</script>

<template>
  <Child :title="msg" :count="3" />
</template>

<!-- Child.vue -->
<script setup>
defineProps({
  title: String,
  count: Number
})
</script>

<template>
  <h2>{{ title }}</h2>
  <p>剩余次数：{{ count }}</p>
</template>

父组件用 :title="msg" 把数据绑给子组件的 props，子组件用 defineProps 声明接收的类型。注意 props 名字在子组件里是 title，不是 msg——msg 是父组件自己的变量名，两者通过模板里的绑定关系对应，不要搞混。

💡 小提示：props 适合"配置型"数据，比如标题、初始值、是否禁用。它不适合传那些会被多个地方反复修改的状态，那种该交给下面的 Pinia。

三、$emit 子传父：子组件回传事件

子组件不能改 props，但可以把"用户点击了""输入变了"这类事件通过 $emit 抛给父组件，由父组件决定怎么处理。这是子传父唯一正规的途径，保证了数据修改的主动权留在父层。

<!-- Child.vue -->
<script setup>
const emit = defineEmits(['submit'])
function onSave() {
  emit('submit', { ok: true })
}
</script>

<template>
  <button @click="onSave">保存</button>
</template>

<!-- Parent.vue -->
<script setup>
import Child from './Child.vue'
function handleSubmit(payload) {
  console.log('子组件回报：', payload)
}
</script>

<template>
  <Child @submit="handleSubmit" />
</template>

子组件用 defineEmits 声明自己会发出哪些事件，调用 emit('submit', 数据) 把数据带上；父组件用 @submit 监听。这样父组件拿到了子组件的反馈，又保住了修改数据的控制权。要学 Vue3 的组合式写法细节，Vue3 组合式教程里对 defineEmits、<script setup> 讲得更细，可对照本项目改造。

⚠️ 注意：不要用 emit 去"反向改 props"，那会破坏单向流。子组件只负责通知"发生了什么"，改数据的逻辑写在父组件里。

四、provide/inject 跨层级共享数据

当组件嵌套很深，祖先想给底层组件数据，用 props 就得一层层往下透传，中间每一层都得多写一遍，又臭又长。provide/inject 允许祖先直接"提供"数据，任意后代"注入"使用，跳过中间层。

<!-- Ancestor.vue -->
<script setup>
import { provide, ref } from 'vue'
const theme = ref('dark')
provide('theme', theme)
</script>

<!-- DeepChild.vue -->
<script setup>
import { inject } from 'vue'
const theme = inject('theme', 'light')
</script>

<template>
  <p>当前主题：{{ theme }}</p>
</template>

祖先用 provide('theme', 值) 共享，后代用 inject('theme', 默认值) 取。第二个参数是取不到时的兜底，建议总写上，避免某个层级漏了 provide 导致拿空。它适合"全局配置""当前用户"这类不常变、跨多层的只读或半只读数据。

不过 provide/inject 也有代价：数据来源不像 props 那样一眼可见，追踪谁改了它比较费劲。如果你的后台界面基于 Element Plus 搭建，Element Plus 教程的组件示例里能看到更多真实嵌套结构，便于你判断哪些数据该用注入、哪些该用状态库。

五、五种 vue 组件通信方式怎么选不纠结

说到这里，四种基础方式之外，Pinia 是处理"多组件共享可变状态"的终极方案。它把状态集中到一个 store，任何组件都能读能改，且改动的来源清晰可追踪，适合购物车、登录用户、全局开关这类场景。

// stores/counter.js
import { defineStore } from 'pinia'

export const useCounter = defineStore('w3cschool-counter', {
  state: () => ({ n: 0 }),
  actions: {
    add() { this.n++ }
  }
})

<!-- AnyComponent.vue -->
<script setup>
import { useCounter } from './stores/counter'
const store = useCounter()
</script>

<template>
  <button @click="store.add">加一：{{ store.n }}</button>
</template>

选型其实有清晰口诀：直接父子用 props + $emit；跨多层只读配置用 provide/inject；多个不相邻组件都要改的共享状态用 Pinia。把 vue 组件通信按"距离和共享范围"分好类，代码就清爽了，新人接手也能一眼看懂数据从哪来、到哪去。

Vue 四种组件通信方式分别适用什么场景

总结

Vue 组件通信的核心是"按距离选方式"：props 父传子把数据往下送，$emit 子传父把事件往上抛，provide/inject 让祖先跨层直接给后代送数据，Pinia 则统一管理被多处修改的共享状态。这四种覆盖了绝大多数业务。

你应当带走的要点：单向数据流是 props 的底线，子组件用 $emit 通知而不是改；provide/inject 省去透传但要小心来源追踪；Pinia 专治"多组件共享可变状态"的乱象。下一步建议把本文四个示例接到你自己的项目里跑一遍，遇到跨页共享就上 Pinia，遇到简单父子就回归 props，选型自然不再纠结。

延伸学习

想把这块知识系统补齐，可以按这个顺序来：

先跟着 Vue.js三天学习实战教程在真实项目里把四种通信方式练熟；
碰到选型拿不准，回看这篇 Vue 组件通信方式详解笔记补充对比；
需要父组件直接调子组件方法时，参考父子组件方法调用笔记的写法示例。

常见问题

Q：子组件能不能直接修改 props？

不能，Vue 会报警告。props 是单向数据流，子组件只负责接收。想改就通过 $emit 把意图告诉父组件，由父组件修改后重新传下来，这样数据源头始终唯一、好追踪。

Q：provide/inject 和 Pinia 该用哪个？

provide/inject 适合跨多层、很少变、偏配置类的数据（如主题、当前语言）；Pinia 适合被多个组件反复读取和修改后的业务状态（如购物车、用户信息）。前者轻量、后者可追踪，按"会不会被多处改"来判断。

Q：频繁的父子传值会导致性能问题吗？

props 和 $emit 本身开销极小，不必担心。真正要警惕的是把本该局部的临时状态塞进全局 Pinia，造成不必要的响应式扩散。数据该放在哪一层，就放在哪一层，能显著提升可维护性。