加载中...

组件通信：Props 传值传到手抽筋

发表于2025-12-31|更新于2026-02-09|Vue学习之路

|浏览量:

Props, Emit, Provide, Inject…

Vue 的组件通信方式多达十几种。父子通信用 Props/Emit，跨层级用 Provide/Inject，兄弟组件用 EventBus（Vue 3 移除了，得自己手写或用mitt），全局状态用 Pinia。

传值的痛苦

当你有 5 层组件嵌套，最外层的组件想传个 ID 给最里面的组件。
Props Drilling（属性透传）简直是灾难。

Parent -> Child -> GrandChild -> GreatGrandChild -> Target

每一层都要声明 Props，写得我想吐。虽说可以用 provide/inject，但不仅失去了类型推断的便利（TS 还要额外定义 InjectionKey），而且数据流变得难以追踪。

文章作者: llbzow

文章链接: https://yourblog.com/2025/12/31/vue-learning-7/

版权声明: 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 llbzow的摸鱼日记 (づ￣ 3￣)づ！

Vue 前端 Vue3 组件

相关推荐

梦开始的地方记得刚接触前端的时候，大家还在用 jQuery 一把梭。那时候的代码充满了 $ 符号，回调地狱更是家常便饭，三件套东一块西一块是常态。后来 React 和 Vue 横空出世，带给了我们全新的组件化开发体验。而今天，我正式决定投入 Vue 3 的怀抱。为什么选择 Vue 3？有人说 React 更灵活，有人说 Angular 更规范。但在我看来，Vue 3 找到了优雅与性能的完美平衡点。性能的质变：Vue 3 重写了响应式系统，利用 ES6 的 Proxy 取代了 Object.defineProperty。这意味着什么？意味着我们再也不用担心数组下标修改监听不到的问题了！而且，初始化的速度快得惊人。 Composition API：这绝对是 Vue 3 最大的杀手锏。在 Options API 时代，一个功能的逻辑往往分散在 data、methods、computed 里，维护起来像是在玩“找你妹”。而现在，我们可以像这就写原生 JS 一样，把相关逻辑聚合在一起。这简直是代码组织的神器！ TypeScript 支持：Vue 2 对 TS 的支持简直是灾难，而 V...

深坑记录：响应式丢失的那一夜

那个让我通宵的 Bug那是周五的晚上，本该是快乐的周末开始。但是测试报了一个致命 Bug：用户点完保存，列表数据没有更新，必须刷新页面才行。排查过程查接口：后端接口返回的数据是新的，没问题。查 Vue DevTools：发现 store 里的数据确实可以更新，但是组件里的数据没变。定位代码： 12345// store.jsstate: () => ({ list: [] })// component.vueconst { list } = userStore 就是这行解构！在 Options API 里习惯了 this.list，在 Setup 里直接解构 store，导致 list 变成了一个普通的数组，失去了响应性连接。心态崩了毁灭吧，赶紧的。累了。我们先来聊聊 Vue 响应式的核心概念。在官方文档中，这一部分被描述得非常晦涩难懂。我花了整整三天时间查阅源码，翻遍了 GitHub 上的 Issues，才勉强理解了其中的奥妙。简单来说，它就像是一个黑盒子，你输入 A，它输出 B，但中间发生了什么，只有上帝和尤雨溪知...

Ref vs Reactive：响应式的哲学思考 (头秃篇)

响应式的哲学在深入学习 Vue 3 的过程中，不管是新手还是老鸟，都会遇到一个经典问题：ref 和 reactive 到底用哪个？官方的定义 ref：接受一个内部值并返回一个响应式且可变的 ref 对象。ref 对象仅有一个 .value property，指向该内部值。 reactive：返回对象的响应式副本。看起来很简单，对吧？ref 处理基本类型，reactive 处理对象。但是在实际开发中，情况远比这复杂。踩坑实录我曾经试图用 reactive 去定义一个数组，结果发现直接重新赋值会丢失响应性！ 123let list = reactive([])// ... 异步获取数据后list = newData // ❌ 响应性丢失！界面不更新！为什么？因为 reactive 返回的是一个 Proxy 对象，直接赋值 list = newData 只是修改了变量 list 的引用，并没有修改原来的 Proxy 对象。正确做法是用 ref，或者用 list.push(...newData)。但是 ref 每次都要写 .value，真的好烦啊！在模板里倒是会自动解包，但...

生命周期钩子：生老病死，Vue 组件的一生

组件的一生万物皆有灵，Vue 组件也不例外。它们从被创建（Creation），到挂载（Mounting），到更新（Updating），最后销毁（Unmounting），走完了一生。而我们开发者，就是那个掌握生杀大权的神。 Vue 3 的变化在 Vue 2 中，我们熟悉的是 created, mounted, destroyed。在 Vue 3 的 Composition API 中，这些变成了 onMounted, onUnmounted 等等。最让我困惑的是 setup()。它在 beforeCreate 和 created 之前执行。这意味着在 setup 里面，我们不需要写这一类的钩子了，直接写逻辑就行。实际应用中的坑我曾经遇到过一个 Bug，在 onMounted 里面去获取 DOM 元素的高宽。理论上这时候 DOM 已经渲染好了，对吧？错！如果你的组件里面有 v-if 或者异步组件，onMounted 触发的时候，子组件可能还没渲染完！这时候拿到的高度是 0。解决办法是用 nextTick，或者检查你的组件结构。为什么会这样？回想起刚开始接触 Vue 的时候，那...

Composition API：逻辑复用的快乐与痛苦

组合式 API：双刃剑Composition API 是 Vue 3 的灵魂。它允许我们将逻辑通过 Hooks（Composables）的方式进行提取和复用。理想很丰满我想象中的代码： 123const { user } = useUser()const { articles } = useArticles()const { loading } = useLoading() 清爽、干净、模块化。现实很骨感实际写出来的代码： 123const { user, loading: userLoading, error: userError } = useUser()const { articles, loading: articleLoading, error: articleError } = useArticles()// 命名冲突！到处重命名！而且，如果你把所有逻辑都堆在 setup 里，不加以拆分，它就会变成一个巨大的面条代码（Spaghetti Code），比 Opt...

前端性能优化：只要我跑得够快，Bug 就追不上我

性能优化：无底洞说页面加载太慢，要优化。好，我优化。你知道的，一个three.js地图，配上一大堆数据，能加载的快就有鬼了。漫漫长路代码分割（Code Splitting）：路由懒加载，组件异步加载。好，首屏快了一点。图片压缩：上了 WebP，上了 CDN。减少重排重绘：小心翼翼地操作 DOM。 Tree Shaking：检查打包产物，去掉了无用的 lodash 引入。结果呢？乐了，更卡了。心态崩了毁灭吧，赶紧的。累了。为什么这么难？前端不就是画画界面调调接口吗？为什么要搞这么复杂？Webpack 还没整明白，Vite 又来了；Vue 3 又变了。学不动了，真的学不动了。