Vue 项目一旦从单页面走向组件协作，通信问题就会立刻成为主线。很多页面并不是不会写，而是父子组件、表单组件、弹窗组件、列表组件之间的数据和意图传来传去之后，边界开始模糊，最后谁都能改状态、谁都能触发流程。
所以这一篇真正要解决的，不是把 props、emit、slot、provide/inject 过一遍，而是要回答一个更底层的问题：组件之间到底应该怎样协作，才能让数据流清楚、责任稳定、页面长期可维护。
为什么通信问题本质上是边界问题？
因为组件从来不是孤立存在的。一个真实页面里，经常同时有：
- 页面容器组件；
- 筛选栏组件；
- 表格组件；
- 分页组件；
- 编辑弹窗组件；
- 表单字段组件；
- 通用布局和操作条组件。
这些组件之间不只是“传值”，而是在协作完成一段业务流程。如果边界没想清楚，通信方式就会被误用，最后出现：
- 子组件直接改父状态；
- 父组件把太多细节硬塞给子组件；
- 多层透传越来越长；
- 组件越来越难复用。
所以通信方式的选择，本质上是在选边界。
props 的核心作用是什么？
props 的价值，不只是让父组件给子组件传数据，而是在表达一件非常重要的事：输入由外部提供，子组件不拥有这份数据的最终控制权。
这意味着：
- 子组件应把
props看成外部输入； - 如果要修改，通常应通过事件告诉拥有者去改；
props命名应该尽量体现业务含义，而不是只剩data、item这种模糊名字；- 一个组件的输入越清晰，它越容易被理解和复用。
真正成熟的组件，往往能从 props 上直接看出它的职责范围。
为什么 Vue 一直强调单向数据流？
因为复杂页面最怕“状态责任不清”。单向数据流的核心意思是：
- 状态从上往下传；
- 意图从下往上抛；
- 修改回到状态拥有者那里发生。
这会让你在排查问题时更容易回答：
- 这份状态归谁管？
- 谁触发了变更？
- 为什么界面现在是这个样子？
如果父子组件之间都能直接乱改彼此状态，页面短期看似方便，长期几乎一定失控。
emit 不是“通知一下”，而是表达用户意图
很多人写事件时会习惯用很泛的名字，比如 change、update、submit，然后把各种业务动作都包在里面。更稳的做法是把事件看成“子组件向外表达意图”的接口。
也就是说，子组件更适合说：
- 用户点击了保存；
- 某个筛选条件改变了；
- 当前表格页码切换了；
- 某个字段请求打开弹窗。
至于这件事接下来怎样处理，是立即请求、更新状态、还是先校验，再交给父层判断。这样一来，组件就不会被业务流程绑死。
slot 真正解决的是哪类问题？
很多人把 slot 理解成“往组件里塞一段内容”。这个理解有点过浅。slot 真正解决的是：当组件结构稳定，但内部某些区域需要由外部决定内容时，怎样保持复用和灵活度。
典型场景包括：
- 表格列的自定义单元格；
- 弹窗头部和底部操作区；
- 列表项内部局部区域；
- 布局组件中的工具栏、筛选栏、空状态区域。
也就是说，slot 不是为了逃避组件设计，而是为了让“结构归组件、内容由外部定制”这件事更自然。
provide / inject 什么时候用才合适？
这是最容易被两极化看待的一组能力。有人几乎不用，层层传 props；有人一觉得传值麻烦就开始注入。更稳的理解方式是：
- 它适合表达“祖先组件向后代提供上下文能力”；
- 它不适合替代常规的父子通信主线；
- 它特别适合共享一些结构性上下文，而不是临时业务状态。
典型合适场景包括：
- 表单容器给表单项提供上下文；
- 主题、布局、权限上下文；
- 组件族内部的协作能力。
如果一段核心业务状态被大量 provide / inject 传播，却没人清楚最终拥有者是谁，那后面通常会越来越难维护。
多层组件透传时，应该怎么办？
这是组件树一深就会碰到的问题。很多人一开始会陷入两个极端：
- 所有东西都层层
props传到底； - 一觉得烦就全局 store 或
provide / inject。
真正更稳的做法，是先判断这份数据到底属于哪一层：
- 如果是局部协作数据，适当透传并不一定有问题；
- 如果是组件族内部上下文，可以考虑
provide / inject； - 如果是跨页面、跨模块共享状态，才考虑全局状态；
- 如果只是某个行为入口，优先用事件向上表达意图。
也就是说，不要先问“用哪个 API”，先问“这份状态或能力到底属于谁”。
把通信问题放回真实项目里，最重要的是什么？
在真实 Vue 项目里，通信设计通常直接决定了这几个东西：
- 页面状态是否可追踪；
- 组件是否真的可复用；
- 表单、弹窗、表格等高频结构是否容易协作；
- 重构时影响面是否可控。
很多项目后期难维护，不是因为 Vue 难，而是因为通信方式把边界彻底抹平了。尤其是在中后台场景里，如果筛选栏、列表、详情、编辑弹窗之间没有清晰数据流，页面很快就会进入“谁都能改一点，谁也说不清为什么”的状态。
最常见的组件通信误区
1. 直接修改 props
这通常是在绕开状态拥有者，短期省事，长期会把数据流搞乱。
2. 事件名太模糊
导致父层收到事件后，根本看不出子组件真正想表达什么。
3. slot 和 props 职责不清
有的内容其实应该用输入参数表达，有的区域才适合交给插槽定制。
4. provide / inject 滥用
最后重要业务状态藏在深层注入里，排查极其痛苦。
总结
Vue 组件通信真正要解决的，不是“值怎么传过去”，而是“责任怎样保持清楚”。props 负责表达输入，emit 负责表达意图，slot 负责在稳定结构里开放内容定制，provide / inject 则适合有限范围内的上下文共享。只要你始终围绕单向数据流去设计通信，组件就更容易复用，页面也更容易维护。