我第一次在生产环境里写 Vue.js是在一个后台管理项目的表格页面上习惯性地在点击事件里用document.querySelector去改样式结果被代码评审的同事一句“你这不等于没学 Vue”怼了回来。当时我嘴上不服心里却很清楚我只是把 Vue 当成一个“自动补全 HTML 的模板库”完全没有进入数据驱动的门。后来带过几批前端新人我发现绝大多数人学 Vue 都会经历同样的别扭期——不是看不懂文档而是思维方式没有切换过来。这篇内容不是什么系统教程是我从“会用”到“能干活”再到“愿意回头啃原理”这段路上的心得整理。没有按文档目录讲而是按我实际踩坑的顺序讲。适合刚学完 Vue 基础、正准备上手写真实项目的人也适合写过一阵子但总觉得代码越来越乱、想理清思路的人。1. 初学 Vue 时最容易跳进去的“命令式思维”大坑1.1 一个让我尴尬的代码评审现场那个后台项目的需求很简单表格里有一列状态点击按钮后状态从“待审核”变成“已通过”同时按钮颜色从橙色变绿色。我当时的做法是在按钮的click回调里先拿到当前行的id然后document.getElementById(status- id)去改innerText再classList换个类名。功能确实跑通了但同事问我一个问题“如果这个状态是从接口返回的刷新之后你手动改的 DOM 还在吗”我答不上来。因为我的逻辑完全绕过了 Vue 的数据层直接修改了 DOM。Vue 的响应式系统根本不知道我干了什么下一次任何数据更新触发重新渲染时我手动改的那些 DOM 全会被还原。这暴露的是典型的命令式思维拿到元素改元素——这是 jQuery 时代被训练出来的肌肉记忆。1.2 命令式思维和声明式思维的分水岭Vue 骨子里是声明式的。什么叫声明式你只需要描述“状态是什么样页面就应该是什么样”至于怎么把一个状态变成一个按钮、一段文字、一个 class那是 Vue 内部渲染器的工作。我后来给新人讲的时候经常用一个非常俗但有效的公式view f(state)视图是状态的函数。你负责维护stateVue 负责把state的变化映射到view。一旦你接受了这个设定很多写法都会自然改变。同样是上面那个按钮状态更新的需求用 Vue 的写法应该是script setup import { ref } from vue const rowStatus ref(pending) // pending | approved const statusMap { pending: { text: 待审核, btnClass: btn-orange }, approved: { text: 已通过, btnClass: btn-green }, } /script template button :classstatusMap[rowStatus.value].btnClass clickrowStatus approved {{ statusMap[rowStatus.value].text }} /button /template这里我没有写一行操作 DOM 的代码按钮的文字和颜色完全由rowStatus这一个变量决定。变量一变视图跟着变。这就是声明式的核心体验你不指挥 Vue 做事你只告诉它“现在状态是什么”。1.3 怎么判断自己有没有真正转过来我总结过几个典型的“命令式思维残留”特征中两条以上的基本说明还停在表面到处用 ref 获取 DOM 元素再手动改它的textContent、className在模板里写v-if控制元素显示又在 JS 里通过display: block/none操作同一个元素数据已经存在ref里了UI 上却还维护着另一份“展示值”手动保持同步提交表单时先查 DOM 里的输入值而不是直接读响应式数据。这些习惯的共同问题是你自己开了一条绕过数据层的小路。短期看省事长期看一旦组件复杂起来DOM 和数据的同步就会彻底失去一致性。2. 响应式原理从 ref 到 reactive我花了两周才真正看懂2.1 从 defineProperty 到 ProxyVue3 换引擎的根本原因如果你只是看文档用 ref 和 reactive 可能一上午就能上手。但不懂底层碰到“为什么这个属性变了页面没刷新”的时候就会完全无从下手。Vue2 的响应式是基于Object.defineProperty实现的。它的问题很典型只能拦截对象已有属性的读写新增和删除属性是拦截不到的。所以 Vue2 里才有一堆补救方法Vue.set、Vue.delete还有数组下标修改失效的历史遗留问题。Vue3 换成了Proxy可以直接拦截整个对象的get、set、deleteProperty等操作所以新增属性、删除属性都能触发更新数组再也不是“二等公民”。两者的本质区别可以看这张表对比项Object.defineProperty (Vue2)Proxy (Vue3)拦截范围单个属性整个对象新增属性不触发更新需用 Vue.set自动触发删除属性不触发更新需用 Vue.delete自动触发数组下标修改不触发更新要改写数组方法自动触发嵌套对象初始化时递归劫持访问时按需代理用生活化的类比来说Vue2 像是在你家的每个房间门口装一个感应器房间变多了你得手动去装Vue3 直接在你家大门口装了一个监控任何人带任何东西进出你都知道。2.2 手写一个极简 ref看清拦截的本质ref 的本质是reactive的语法糖用一个对象包装基本类型然后通过 getter/setter 来做依赖收集和更新触发。我试着写了一个简化版能帮你建立最直观的认识function myRef(initialValue) { let _value initialValue // 用一个 Set 存那些“用到了这个值”的副作用函数 const deps new Set() return { get value() { // 读取时进入“收集状态” if (currentEffect) { deps.add(currentEffect) } return _value }, set value(newValue) { _value newValue // 值变了把所有依赖它的函数重新执行一遍 deps.forEach((effect) effect()) }, } }当然真实源码比我这个复杂得多但核心逻辑不外乎读的时候记住谁在用写的时候告诉用的人“东西变了请你重新跑一遍”。这就是 Vue3 整套响应式系统的心脏。搞懂了这个再看computed、watch你会发现它们的本质都非常清楚一个是被缓存起来的副作用一个是主动监听的副作用。2.3 ref 和 reactive 的选型团队规范比个人偏好更重要ref和reactive到底用哪个官方文档说“用哪种都行”但真实项目里这必须是一个统一约定否则代码风格会迅速失控。我的个人建议是默认用 ref包括对象和数组也用 ref。原因主要有三个ref 在模板里会自动解包模板里写rowStatus而不是rowStatus.value心智负担小ref 传进函数、组合式函数里时始终是一个对象引用不会在传递过程中丢失响应性reactive 有一个很隐蔽的坑解构出来的属性会丢失响应性逼着你额外用toRefs不如一开始就统一用 ref。当然 reactive 也不是完全没用。如果你处理的是一个深层嵌套、结构固定的表单对象而且不想每层都写.valuereactive 更方便。但那种场景我一般也会建议用ref包一层宁可多写几个.value也不会在不同写法之间来回横跳。2.4 响应式丢失解构时悄悄发生的事“响应式丢失”这个问题几乎所有用 reactive 的人都会遇到。看这段代码const form reactive({ name: 张三, age: 30 }) const { name, age } formname和age在解构之后就变成了普通的字符串和数字和form.name的响应式联系彻底断了。你在组件里改name页面不会刷新。这不是 Bug这是 JavaScript 解构的天然行为——基本类型的值传递本来就是复制不是引用。解决方案是toRefsconst { name, age } toRefs(form)现在name和age是 ref 对象指向的是form内部的属性。但说实话与其跟toRefs纠缠我更推荐前面说的“默认 ref”策略。一个form用ref包着组件里访问就统一是form.value.name解构时直接const { name } form.value也行——因为解构出来的是一个响应式数据的快照配合 template 自动解包反而直观。3. 组件通信的“梯度选择法”别一上来就引状态管理库3.1 先用好 props 和 emit90% 的组件通信不需要进阶方案很多新手学完组件通信第一反应是“凡是多个组件要用的数据我就上 Vuex/Pinia”。这是一个代价很高的误区。状态管理是双刃剑引入之后你多了一个全局数据源要维护调试难度也随之上升。正确的思路应该是梯度选择能用局部方案解决就不上全局方案。最基础的通信方式是propsemit一个负责向下传数据一个负责向上传事件。!-- 子组件 Child.vue -- script setup const props defineProps({ count: { type: Number, required: true, }, }) const emit defineEmits([update:count]) function addOne() { emit(update:count, props.count 1) } /script template button clickaddOne当前计数{{ count }}点我 1/button /template父组件script setup import { ref } from vue import Child from ./Child.vue const total ref(0) /script template Child :counttotal update:counttotal $event / /template这里有几个关键点都是踩过坑的经验props 必须是单向的子组件不能直接改 props 的值否则数据流会变得不可追踪$event在模板里就是 emit 出来的那个参数如果嫌update:counttotal $event啰嗦可以用v-model简化。3.2 v-model 是 props emit 的语法糖看完上面那段代码你应该已经感觉到了v-model本质上是“一个 prop 一个 emit”的组合写法。组件上的v-model会被编译成:modelValue和update:modelValue。Vue3.4 之后有了defineModel宏写法更简洁了script setup const model defineModel() /script template input v-modelmodel / /template这里的model是一个可以在子组件里直接读写的 ref父组件传进来的值和子组件的修改会自动双向同步。我刚接触defineModel的时候有点犹豫觉得它把“单向数据流”的界限模糊了。后来想通了它并没有破坏单向数据流只是把“props 向下、事件向上”这个流程封装成了一个语义更清晰的黑盒。业务组件内部用defineModel做双向绑定非常顺手。3.3 provide/inject 的适用边界props 只能一层层往下传如果数据要从最外层传给第五层子组件中间所有层级都要写一遍props又丑又难维护。这时候provide和inject就有用了祖先组件提供数据任意深度的后代组件直接注入使用。// 祖先组件 import { provide, ref } from vue const theme ref(light) provide(theme, theme)// 任意后代组件 import { inject } from vue const theme inject(theme)用provide的时候有一个很容易踩的坑默认情况下你 provide 出去一个普通变量的值子组件拿到的就是那个值的一份拷贝不会自动更新。要让注入方响应式变化必须 provide 一个 ref 或 reactive 对象。官方文档其实写了但很多人没注意。provide/inject也不是万能的。它适合“全局配置类”的数据比如当前用户信息、主题、语言等这些数据在整个应用里基本是稳定的。但如果这个数据频繁变化、参与复杂逻辑注入方又分布在各个层级的组件中建议还是考虑 Pinia。因为 provide/inject 缺少中间层改数据的时候你很难迅速定位“到底是谁改了它”。3.4 什么时候才轮得到 Pinia我个人判断要不要引 Pinia 的标准不是“多个组件用同一个数据”而是看数据是否满足这两个特征跨多个页面或跨多个不相邻的组件树共享且会频繁变化同一份业务数据要同时被页面展示、接口提交、路由参数等多个入口读写。有个典型例子登录状态。用户信息在导航栏、个人中心、路由守卫、请求拦截器里都要用而且会在登录、刷新、退出等不同时机被修改。这种数据用 props 传会传崩溃用 provide/inject 又缺少数管理能力最合适的就是一个 Pinia store。相反如果只是“购物车浮层”和“商品列表页”需要同步一个商品数量我会先考虑把它们抽取到一个composable比如useCart()组件内各自调用配合一个共享的 ref 状态。这样不动用 Pinia代码量少调试也简单。通信场景推荐方案理由父子组件传参props单向数据流最清晰子组件通知父组件emit事件语义明确父子双向绑定defineModel / v-model语法糖简洁深层嵌套传递稳定数据provide / inject跳过中间层级跨页面/跨模块共享频繁变化数据Pinia store集中管理和调试4. 生命周期与数据请求的时序问题onMounted 里的那些意外4.1 Vue3 生命周期和 Vue2 的对应关系很多从 Vue2 转过来的人会被setup替代created和beforeCreate这件事绕晕。简单对应关系是Vue2 生命周期Vue3 对应说明beforeCreate / createdsetupsetup 本身就是这个阶段beforeMountonBeforeMount挂载前mountedonMounted挂载完成beforeUpdateonBeforeUpdate响应式数据变化即将重新渲染updatedonUpdated重新渲染完成beforeDestroyonBeforeUnmount卸载前destroyedonUnmounted卸载完成activated / deactivatedonActivated / onDeactivated配合 keep-alive 使用4.2 异步请求的时机setup 顶层还是 onMounted?新手最常见的疑问既然setup替代了created那我是不是应该在setup顶层直接发请求答案是不能。setup是组件实例创建过程中同步执行的如果在setup里直接await一个请求组件会一直等异步完成才继续初始化期间模板还没法渲染。这会造成白屏时间不可控。除非你配合Suspense使用否则不要这么干。正确的姿势是onMountedimport { ref, onMounted } from vue const list ref([]) const loading ref(true) onMounted(async () { try { const res await fetch(/api/list) list.value await res.json() } catch (e) { console.error(加载列表失败, e) } finally { loading.value false } })注意onMounted在服务端渲染场景下不会执行但前端项目里这个不是主要问题。真正的问题是很多人把请求逻辑直接堆在onMounted里一多就乱。我的习惯是把请求逻辑拆成独立的函数或 composableonMounted里只负责调用。这样组件卸载再挂载、或者要手动刷新的时候复用起来极其方便。4.3 keep-alive 场景下的生命周期差异页面加了keep-alive之后生命周期时序就变了。第一次进入组件会执行onMounted和onActivated但组件被缓存后再次进入时onMounted不会再执行只有onActivated会触发。这个差异坑了我一次项目里有个列表页我按惯例在onMounted里请求数据。第一次进页面没问题从详情页返回列表页时页面从缓存中恢复但数据还是旧的“自动刷新”的预期落空了。后来我把“进入页面时的刷新逻辑”从onMounted挪到了onActivatedimport { onActivated, onMounted } from vue // 首次挂载才执行的一次性初始化 onMounted(() { scrollContainer.value document.querySelector(#list-container) }) // 每次从缓存中激活都会执行 onActivated(async () { await fetchList() restoreScroll() })4.4 一个滚动位置恢复的实战案例列表页滚动位置恢复是一个非常经典的需求。用户在列表页滚到第 300 行点进详情页返回列表页时如果页面被keep-alive缓存滚动位置应该自然保留但如果页面没有被缓存就需要手动保存和恢复。完整做法大概分三步在onBeforeUnmount里记下当前滚动位置在onActivated如果用了 keep-alive或onMounted里恢复位置用nextTick确保 DOM 已经渲染完成后再scrollTo。import { nextTick, onBeforeUnmount, onMounted } from vue let scrollTop 0 onBeforeUnmount(() { scrollTop container.value.scrollTop }) onMounted(async () { await nextTick() container.value.scrollTop scrollTop })这里为什么用nextTick因为数据变化触发视图更新是异步的你立刻scrollTop时 DOM 还是旧的高度不对位置就不对。nextTick就是“等 Vue 完成本次 DOM 更新”的钩子。生命周期和异步时序的问题用好了nextTick能解决一大半。5. 把模板用“活”插槽、动态组件和异步加载是我提升最大的三个点5.1 三种插槽默认、具名、作用域如果说 props 是组件的“参数”那插槽就是组件的“内容占位”。默认插槽就是最普通的slot /具名插槽适合布局型组件比如弹窗的头部、主体、底部作用域插槽则是“让父组件接管子组件的渲染细节”。举一个最实用的例子一个数据表格组件表格的行渲染逻辑千变万化不可能所有列都写死。用作用域插槽可以让使用方决定某一列显示什么!-- Table.vue -- script setup defineProps({ columns: Array, data: Array, }) /script template table thead tr th v-forcol in columns :keycol.key{{ col.title }}/th /tr /thead tbody tr v-forrow in data :keyrow.id td v-forcol in columns :keycol.key slot :namecol.key :rowrow {{ row[col.key] }} /slot /td /tr /tbody /table /template使用方可以这样覆盖某个列的渲染template Table :columnscolumns :datarows template #status{ row } span :classrow.status ok ? text-green : text-red {{ row.status }} /span /template /Table /template这就是作用域插槽的本质子组件提供数据父组件决定怎么展示。掌握这一点你的通用组件设计能力会上一个大台阶。5.2 动态组件让模板具备运行时切换能力component :is...是另一个改变写法的能力。比如一个 Tab 切换场景以前可能是三个v-if块模板非常臃肿。有了动态组件一个标签就搞定了script setup import { ref } from vue import UserInfo from ./UserInfo.vue import OrderList from ./OrderList.vue import AddressList from ./AddressList.vue const tabs { info: UserInfo, order: OrderList, address: AddressList, } const activeTab ref(info) /script template button v-for(_, key) in tabs :keykey clickactiveTab key {{ key }} /button component :istabs[activeTab] / /template动态组件结合keep-alive还能实现“切换 Tab 保留输入内容”的效果。这个组合应该是每个做后台系统的前端都绕不开的工具。5.3 异步组件首屏加载的“减重”手段Vue 3 里用defineAsyncComponent配合import()做异步组件可以把首屏不用立即渲染的组件拆成独立包浏览器真正需要它的时候才加载。import { defineAsyncComponent } from vue const OrderDetail defineAsyncComponent(() import(./OrderDetail.vue))这个功能优化首屏体积效果非常直观。比如一个后台管理系统的路由懒加载其实底层也是异步组件机制。区别是路由懒加载以“页面”为单位拆分异步组件可以更细粒度地拆“弹窗”“抽屉”“图表区域”这些局部模块。配合Suspense还能实现占位内容Suspense component :istabs[activeTab] / template #fallback div加载中.../div /template /Suspense5.4 模板性能的四个自查点模板性能问题不一定影响首屏但一定影响交互流畅度。我每次代码评审都会重点看这几个点v-for 一定要加 key。key 是组件复用的标识不加 key 会导致列表更新时复用策略出错有可能渲染出错误内容v-for 和 v-if 不要放在同一个元素上。Vue3 里v-if的优先级比v-for高写在一起容易造成“v-if 判断时变量还不存在”的奇怪问题逻辑也不好读。把它们拆开或者用计算属性过滤出最终列表再循环用 computed 缓存派生数据。模板里写复杂表达式{{ items.filter(...).map(...).length }}每次渲染都会重新计算。抽成 computed 后只有依赖变了才重算v-show 和 v-if 的选择。高频切换用 v-show低概率/一次性显示用 v-if。v-show 只是切换display但元素始终在 DOM 里v-if 是真的增删节点。6. 三个让我排查到深夜的问题与最终定位思路6.1 数组更新失效问题旧经验害死人背景Vue2 时代直接通过下标修改数组元素arr[0] xxx页面是不会更新的必须用Vue.set或数组的变异方法。这个坑太出名了以至于 Vue3 出来很长时间还有很多人写代码时小心翼翼。在 Vue3 里因为响应式基于 Proxy直接改下标是可以触发视图更新的const list ref([ { name: 张三, done: false }, { name: 李四, done: false }, ]) // Vue3 中这是完全合法的视图会更新 list.value[0].done true要注意一个边界情况通过arr.length 0清空数组Proxy 也能拦截length的变化。所以 Vue3 里基本不用担心数组操作的手段问题了。如果你发现修改数组视图没更新优先检查自己的数据在不在响应式系统里——比如是不是用普通变量存了而不是用 ref/reactive。6.2 computed 里的副作用一个无限循环的错误示范有一次我写了一个 computed目的是用户输入公司名时自动生成 slug生成完之后顺手把它存进了一个响应式 store。结果页面直接卡死控制台报溢出错误。原因很典型computed 内部修改了外部响应式数据而这个数据又是 computed 的依赖。computed 一算改了 storestore 一变computed 依赖变了又重算重算又改 store……形成一个死循环。正确的做法是computed 只能做纯计算不能有副作用。所谓副作用就是对自身之外的响应式变量进行赋值、请求接口、写存储等操作。如果确实需要“输入时同步生成另一个字段”应该用watch或者事件回调import { ref, watch } from vue const companyName ref() const slug ref() watch(companyName, (val) { slug.value val.trim().toLowerCase().replace(/\s/g, -) })6.3 HMR 状态丢失和模块顶层副作用Vue 开发时有个恼人的问题改完代码热更新是生效了但组件状态丢了甚至页面白屏半天。排查时发现问题经常出在“模块顶层代码被执行了两遍”。Vue 的热更新机制是“保留组件实例、替换渲染逻辑”但如果模块顶层有副作用代码HMR 更新时会重新执行模块造成重复注册、重复执行请求等怪问题。比如// main.js console.log(module loaded) // 某些第三方库在模块顶层调用了初始化方法解决思路有三条第一模块顶层只声明不执行把初始化动作挪到组件生命周期或某些钩子里第二如果第三方库必须在模块顶层初始化检查有没有幂等性封装方案比如先判断是否已初始化第三遇到 HMR 异常先刷新页面确认问题是否依然存在如果刷新后消失大概率就是 HMR 与顶层副作用的兼容问题。6.4 排查链路的通用模板踩过太多坑之后我总结出了一套通用的响应式问题排查顺序对新手非常有帮助先确认数据变了没有。在对应位置打日志或断点看响应式变量是否真的被赋了新值再确认依赖被追踪到了没有。数据变了依赖数据的 computed、watch、模板有没有被通知到。如果没通知说明数据不在响应式系统内或者写法破坏了响应式链比如解构、绕过 ref 直接赋值最后确认是不是时序问题。数据变了、依赖也被通知了但视图还没更新——这种情况优先上nextTick处理如果还有问题打开 Vue Devtools 看实时组件树和数据流基本能定位到具体层级的失效点。关于 Vue.js 的学习我的核心体会就一句它的大部分难点不在 API 记不记得住而在于你有没有建立起“数据驱动”的心智模型。API 忘了查文档就行心智模型有了看什么组件都知道它内部大概是怎么运转的。带新人我也从不让对方背 API而是先问三个问题这个数据为什么要放进 ref模板里的这个表达式为什么每次渲染都会重算组件的这个状态从哪来、到哪去、被谁改过思路理清代码乱不到哪去。
Vue3实战：从命令式思维到数据驱动的进阶之路
我第一次在生产环境里写 Vue.js是在一个后台管理项目的表格页面上习惯性地在点击事件里用document.querySelector去改样式结果被代码评审的同事一句“你这不等于没学 Vue”怼了回来。当时我嘴上不服心里却很清楚我只是把 Vue 当成一个“自动补全 HTML 的模板库”完全没有进入数据驱动的门。后来带过几批前端新人我发现绝大多数人学 Vue 都会经历同样的别扭期——不是看不懂文档而是思维方式没有切换过来。这篇内容不是什么系统教程是我从“会用”到“能干活”再到“愿意回头啃原理”这段路上的心得整理。没有按文档目录讲而是按我实际踩坑的顺序讲。适合刚学完 Vue 基础、正准备上手写真实项目的人也适合写过一阵子但总觉得代码越来越乱、想理清思路的人。1. 初学 Vue 时最容易跳进去的“命令式思维”大坑1.1 一个让我尴尬的代码评审现场那个后台项目的需求很简单表格里有一列状态点击按钮后状态从“待审核”变成“已通过”同时按钮颜色从橙色变绿色。我当时的做法是在按钮的click回调里先拿到当前行的id然后document.getElementById(status- id)去改innerText再classList换个类名。功能确实跑通了但同事问我一个问题“如果这个状态是从接口返回的刷新之后你手动改的 DOM 还在吗”我答不上来。因为我的逻辑完全绕过了 Vue 的数据层直接修改了 DOM。Vue 的响应式系统根本不知道我干了什么下一次任何数据更新触发重新渲染时我手动改的那些 DOM 全会被还原。这暴露的是典型的命令式思维拿到元素改元素——这是 jQuery 时代被训练出来的肌肉记忆。1.2 命令式思维和声明式思维的分水岭Vue 骨子里是声明式的。什么叫声明式你只需要描述“状态是什么样页面就应该是什么样”至于怎么把一个状态变成一个按钮、一段文字、一个 class那是 Vue 内部渲染器的工作。我后来给新人讲的时候经常用一个非常俗但有效的公式view f(state)视图是状态的函数。你负责维护stateVue 负责把state的变化映射到view。一旦你接受了这个设定很多写法都会自然改变。同样是上面那个按钮状态更新的需求用 Vue 的写法应该是script setup import { ref } from vue const rowStatus ref(pending) // pending | approved const statusMap { pending: { text: 待审核, btnClass: btn-orange }, approved: { text: 已通过, btnClass: btn-green }, } /script template button :classstatusMap[rowStatus.value].btnClass clickrowStatus approved {{ statusMap[rowStatus.value].text }} /button /template这里我没有写一行操作 DOM 的代码按钮的文字和颜色完全由rowStatus这一个变量决定。变量一变视图跟着变。这就是声明式的核心体验你不指挥 Vue 做事你只告诉它“现在状态是什么”。1.3 怎么判断自己有没有真正转过来我总结过几个典型的“命令式思维残留”特征中两条以上的基本说明还停在表面到处用 ref 获取 DOM 元素再手动改它的textContent、className在模板里写v-if控制元素显示又在 JS 里通过display: block/none操作同一个元素数据已经存在ref里了UI 上却还维护着另一份“展示值”手动保持同步提交表单时先查 DOM 里的输入值而不是直接读响应式数据。这些习惯的共同问题是你自己开了一条绕过数据层的小路。短期看省事长期看一旦组件复杂起来DOM 和数据的同步就会彻底失去一致性。2. 响应式原理从 ref 到 reactive我花了两周才真正看懂2.1 从 defineProperty 到 ProxyVue3 换引擎的根本原因如果你只是看文档用 ref 和 reactive 可能一上午就能上手。但不懂底层碰到“为什么这个属性变了页面没刷新”的时候就会完全无从下手。Vue2 的响应式是基于Object.defineProperty实现的。它的问题很典型只能拦截对象已有属性的读写新增和删除属性是拦截不到的。所以 Vue2 里才有一堆补救方法Vue.set、Vue.delete还有数组下标修改失效的历史遗留问题。Vue3 换成了Proxy可以直接拦截整个对象的get、set、deleteProperty等操作所以新增属性、删除属性都能触发更新数组再也不是“二等公民”。两者的本质区别可以看这张表对比项Object.defineProperty (Vue2)Proxy (Vue3)拦截范围单个属性整个对象新增属性不触发更新需用 Vue.set自动触发删除属性不触发更新需用 Vue.delete自动触发数组下标修改不触发更新要改写数组方法自动触发嵌套对象初始化时递归劫持访问时按需代理用生活化的类比来说Vue2 像是在你家的每个房间门口装一个感应器房间变多了你得手动去装Vue3 直接在你家大门口装了一个监控任何人带任何东西进出你都知道。2.2 手写一个极简 ref看清拦截的本质ref 的本质是reactive的语法糖用一个对象包装基本类型然后通过 getter/setter 来做依赖收集和更新触发。我试着写了一个简化版能帮你建立最直观的认识function myRef(initialValue) { let _value initialValue // 用一个 Set 存那些“用到了这个值”的副作用函数 const deps new Set() return { get value() { // 读取时进入“收集状态” if (currentEffect) { deps.add(currentEffect) } return _value }, set value(newValue) { _value newValue // 值变了把所有依赖它的函数重新执行一遍 deps.forEach((effect) effect()) }, } }当然真实源码比我这个复杂得多但核心逻辑不外乎读的时候记住谁在用写的时候告诉用的人“东西变了请你重新跑一遍”。这就是 Vue3 整套响应式系统的心脏。搞懂了这个再看computed、watch你会发现它们的本质都非常清楚一个是被缓存起来的副作用一个是主动监听的副作用。2.3 ref 和 reactive 的选型团队规范比个人偏好更重要ref和reactive到底用哪个官方文档说“用哪种都行”但真实项目里这必须是一个统一约定否则代码风格会迅速失控。我的个人建议是默认用 ref包括对象和数组也用 ref。原因主要有三个ref 在模板里会自动解包模板里写rowStatus而不是rowStatus.value心智负担小ref 传进函数、组合式函数里时始终是一个对象引用不会在传递过程中丢失响应性reactive 有一个很隐蔽的坑解构出来的属性会丢失响应性逼着你额外用toRefs不如一开始就统一用 ref。当然 reactive 也不是完全没用。如果你处理的是一个深层嵌套、结构固定的表单对象而且不想每层都写.valuereactive 更方便。但那种场景我一般也会建议用ref包一层宁可多写几个.value也不会在不同写法之间来回横跳。2.4 响应式丢失解构时悄悄发生的事“响应式丢失”这个问题几乎所有用 reactive 的人都会遇到。看这段代码const form reactive({ name: 张三, age: 30 }) const { name, age } formname和age在解构之后就变成了普通的字符串和数字和form.name的响应式联系彻底断了。你在组件里改name页面不会刷新。这不是 Bug这是 JavaScript 解构的天然行为——基本类型的值传递本来就是复制不是引用。解决方案是toRefsconst { name, age } toRefs(form)现在name和age是 ref 对象指向的是form内部的属性。但说实话与其跟toRefs纠缠我更推荐前面说的“默认 ref”策略。一个form用ref包着组件里访问就统一是form.value.name解构时直接const { name } form.value也行——因为解构出来的是一个响应式数据的快照配合 template 自动解包反而直观。3. 组件通信的“梯度选择法”别一上来就引状态管理库3.1 先用好 props 和 emit90% 的组件通信不需要进阶方案很多新手学完组件通信第一反应是“凡是多个组件要用的数据我就上 Vuex/Pinia”。这是一个代价很高的误区。状态管理是双刃剑引入之后你多了一个全局数据源要维护调试难度也随之上升。正确的思路应该是梯度选择能用局部方案解决就不上全局方案。最基础的通信方式是propsemit一个负责向下传数据一个负责向上传事件。!-- 子组件 Child.vue -- script setup const props defineProps({ count: { type: Number, required: true, }, }) const emit defineEmits([update:count]) function addOne() { emit(update:count, props.count 1) } /script template button clickaddOne当前计数{{ count }}点我 1/button /template父组件script setup import { ref } from vue import Child from ./Child.vue const total ref(0) /script template Child :counttotal update:counttotal $event / /template这里有几个关键点都是踩过坑的经验props 必须是单向的子组件不能直接改 props 的值否则数据流会变得不可追踪$event在模板里就是 emit 出来的那个参数如果嫌update:counttotal $event啰嗦可以用v-model简化。3.2 v-model 是 props emit 的语法糖看完上面那段代码你应该已经感觉到了v-model本质上是“一个 prop 一个 emit”的组合写法。组件上的v-model会被编译成:modelValue和update:modelValue。Vue3.4 之后有了defineModel宏写法更简洁了script setup const model defineModel() /script template input v-modelmodel / /template这里的model是一个可以在子组件里直接读写的 ref父组件传进来的值和子组件的修改会自动双向同步。我刚接触defineModel的时候有点犹豫觉得它把“单向数据流”的界限模糊了。后来想通了它并没有破坏单向数据流只是把“props 向下、事件向上”这个流程封装成了一个语义更清晰的黑盒。业务组件内部用defineModel做双向绑定非常顺手。3.3 provide/inject 的适用边界props 只能一层层往下传如果数据要从最外层传给第五层子组件中间所有层级都要写一遍props又丑又难维护。这时候provide和inject就有用了祖先组件提供数据任意深度的后代组件直接注入使用。// 祖先组件 import { provide, ref } from vue const theme ref(light) provide(theme, theme)// 任意后代组件 import { inject } from vue const theme inject(theme)用provide的时候有一个很容易踩的坑默认情况下你 provide 出去一个普通变量的值子组件拿到的就是那个值的一份拷贝不会自动更新。要让注入方响应式变化必须 provide 一个 ref 或 reactive 对象。官方文档其实写了但很多人没注意。provide/inject也不是万能的。它适合“全局配置类”的数据比如当前用户信息、主题、语言等这些数据在整个应用里基本是稳定的。但如果这个数据频繁变化、参与复杂逻辑注入方又分布在各个层级的组件中建议还是考虑 Pinia。因为 provide/inject 缺少中间层改数据的时候你很难迅速定位“到底是谁改了它”。3.4 什么时候才轮得到 Pinia我个人判断要不要引 Pinia 的标准不是“多个组件用同一个数据”而是看数据是否满足这两个特征跨多个页面或跨多个不相邻的组件树共享且会频繁变化同一份业务数据要同时被页面展示、接口提交、路由参数等多个入口读写。有个典型例子登录状态。用户信息在导航栏、个人中心、路由守卫、请求拦截器里都要用而且会在登录、刷新、退出等不同时机被修改。这种数据用 props 传会传崩溃用 provide/inject 又缺少数管理能力最合适的就是一个 Pinia store。相反如果只是“购物车浮层”和“商品列表页”需要同步一个商品数量我会先考虑把它们抽取到一个composable比如useCart()组件内各自调用配合一个共享的 ref 状态。这样不动用 Pinia代码量少调试也简单。通信场景推荐方案理由父子组件传参props单向数据流最清晰子组件通知父组件emit事件语义明确父子双向绑定defineModel / v-model语法糖简洁深层嵌套传递稳定数据provide / inject跳过中间层级跨页面/跨模块共享频繁变化数据Pinia store集中管理和调试4. 生命周期与数据请求的时序问题onMounted 里的那些意外4.1 Vue3 生命周期和 Vue2 的对应关系很多从 Vue2 转过来的人会被setup替代created和beforeCreate这件事绕晕。简单对应关系是Vue2 生命周期Vue3 对应说明beforeCreate / createdsetupsetup 本身就是这个阶段beforeMountonBeforeMount挂载前mountedonMounted挂载完成beforeUpdateonBeforeUpdate响应式数据变化即将重新渲染updatedonUpdated重新渲染完成beforeDestroyonBeforeUnmount卸载前destroyedonUnmounted卸载完成activated / deactivatedonActivated / onDeactivated配合 keep-alive 使用4.2 异步请求的时机setup 顶层还是 onMounted?新手最常见的疑问既然setup替代了created那我是不是应该在setup顶层直接发请求答案是不能。setup是组件实例创建过程中同步执行的如果在setup里直接await一个请求组件会一直等异步完成才继续初始化期间模板还没法渲染。这会造成白屏时间不可控。除非你配合Suspense使用否则不要这么干。正确的姿势是onMountedimport { ref, onMounted } from vue const list ref([]) const loading ref(true) onMounted(async () { try { const res await fetch(/api/list) list.value await res.json() } catch (e) { console.error(加载列表失败, e) } finally { loading.value false } })注意onMounted在服务端渲染场景下不会执行但前端项目里这个不是主要问题。真正的问题是很多人把请求逻辑直接堆在onMounted里一多就乱。我的习惯是把请求逻辑拆成独立的函数或 composableonMounted里只负责调用。这样组件卸载再挂载、或者要手动刷新的时候复用起来极其方便。4.3 keep-alive 场景下的生命周期差异页面加了keep-alive之后生命周期时序就变了。第一次进入组件会执行onMounted和onActivated但组件被缓存后再次进入时onMounted不会再执行只有onActivated会触发。这个差异坑了我一次项目里有个列表页我按惯例在onMounted里请求数据。第一次进页面没问题从详情页返回列表页时页面从缓存中恢复但数据还是旧的“自动刷新”的预期落空了。后来我把“进入页面时的刷新逻辑”从onMounted挪到了onActivatedimport { onActivated, onMounted } from vue // 首次挂载才执行的一次性初始化 onMounted(() { scrollContainer.value document.querySelector(#list-container) }) // 每次从缓存中激活都会执行 onActivated(async () { await fetchList() restoreScroll() })4.4 一个滚动位置恢复的实战案例列表页滚动位置恢复是一个非常经典的需求。用户在列表页滚到第 300 行点进详情页返回列表页时如果页面被keep-alive缓存滚动位置应该自然保留但如果页面没有被缓存就需要手动保存和恢复。完整做法大概分三步在onBeforeUnmount里记下当前滚动位置在onActivated如果用了 keep-alive或onMounted里恢复位置用nextTick确保 DOM 已经渲染完成后再scrollTo。import { nextTick, onBeforeUnmount, onMounted } from vue let scrollTop 0 onBeforeUnmount(() { scrollTop container.value.scrollTop }) onMounted(async () { await nextTick() container.value.scrollTop scrollTop })这里为什么用nextTick因为数据变化触发视图更新是异步的你立刻scrollTop时 DOM 还是旧的高度不对位置就不对。nextTick就是“等 Vue 完成本次 DOM 更新”的钩子。生命周期和异步时序的问题用好了nextTick能解决一大半。5. 把模板用“活”插槽、动态组件和异步加载是我提升最大的三个点5.1 三种插槽默认、具名、作用域如果说 props 是组件的“参数”那插槽就是组件的“内容占位”。默认插槽就是最普通的slot /具名插槽适合布局型组件比如弹窗的头部、主体、底部作用域插槽则是“让父组件接管子组件的渲染细节”。举一个最实用的例子一个数据表格组件表格的行渲染逻辑千变万化不可能所有列都写死。用作用域插槽可以让使用方决定某一列显示什么!-- Table.vue -- script setup defineProps({ columns: Array, data: Array, }) /script template table thead tr th v-forcol in columns :keycol.key{{ col.title }}/th /tr /thead tbody tr v-forrow in data :keyrow.id td v-forcol in columns :keycol.key slot :namecol.key :rowrow {{ row[col.key] }} /slot /td /tr /tbody /table /template使用方可以这样覆盖某个列的渲染template Table :columnscolumns :datarows template #status{ row } span :classrow.status ok ? text-green : text-red {{ row.status }} /span /template /Table /template这就是作用域插槽的本质子组件提供数据父组件决定怎么展示。掌握这一点你的通用组件设计能力会上一个大台阶。5.2 动态组件让模板具备运行时切换能力component :is...是另一个改变写法的能力。比如一个 Tab 切换场景以前可能是三个v-if块模板非常臃肿。有了动态组件一个标签就搞定了script setup import { ref } from vue import UserInfo from ./UserInfo.vue import OrderList from ./OrderList.vue import AddressList from ./AddressList.vue const tabs { info: UserInfo, order: OrderList, address: AddressList, } const activeTab ref(info) /script template button v-for(_, key) in tabs :keykey clickactiveTab key {{ key }} /button component :istabs[activeTab] / /template动态组件结合keep-alive还能实现“切换 Tab 保留输入内容”的效果。这个组合应该是每个做后台系统的前端都绕不开的工具。5.3 异步组件首屏加载的“减重”手段Vue 3 里用defineAsyncComponent配合import()做异步组件可以把首屏不用立即渲染的组件拆成独立包浏览器真正需要它的时候才加载。import { defineAsyncComponent } from vue const OrderDetail defineAsyncComponent(() import(./OrderDetail.vue))这个功能优化首屏体积效果非常直观。比如一个后台管理系统的路由懒加载其实底层也是异步组件机制。区别是路由懒加载以“页面”为单位拆分异步组件可以更细粒度地拆“弹窗”“抽屉”“图表区域”这些局部模块。配合Suspense还能实现占位内容Suspense component :istabs[activeTab] / template #fallback div加载中.../div /template /Suspense5.4 模板性能的四个自查点模板性能问题不一定影响首屏但一定影响交互流畅度。我每次代码评审都会重点看这几个点v-for 一定要加 key。key 是组件复用的标识不加 key 会导致列表更新时复用策略出错有可能渲染出错误内容v-for 和 v-if 不要放在同一个元素上。Vue3 里v-if的优先级比v-for高写在一起容易造成“v-if 判断时变量还不存在”的奇怪问题逻辑也不好读。把它们拆开或者用计算属性过滤出最终列表再循环用 computed 缓存派生数据。模板里写复杂表达式{{ items.filter(...).map(...).length }}每次渲染都会重新计算。抽成 computed 后只有依赖变了才重算v-show 和 v-if 的选择。高频切换用 v-show低概率/一次性显示用 v-if。v-show 只是切换display但元素始终在 DOM 里v-if 是真的增删节点。6. 三个让我排查到深夜的问题与最终定位思路6.1 数组更新失效问题旧经验害死人背景Vue2 时代直接通过下标修改数组元素arr[0] xxx页面是不会更新的必须用Vue.set或数组的变异方法。这个坑太出名了以至于 Vue3 出来很长时间还有很多人写代码时小心翼翼。在 Vue3 里因为响应式基于 Proxy直接改下标是可以触发视图更新的const list ref([ { name: 张三, done: false }, { name: 李四, done: false }, ]) // Vue3 中这是完全合法的视图会更新 list.value[0].done true要注意一个边界情况通过arr.length 0清空数组Proxy 也能拦截length的变化。所以 Vue3 里基本不用担心数组操作的手段问题了。如果你发现修改数组视图没更新优先检查自己的数据在不在响应式系统里——比如是不是用普通变量存了而不是用 ref/reactive。6.2 computed 里的副作用一个无限循环的错误示范有一次我写了一个 computed目的是用户输入公司名时自动生成 slug生成完之后顺手把它存进了一个响应式 store。结果页面直接卡死控制台报溢出错误。原因很典型computed 内部修改了外部响应式数据而这个数据又是 computed 的依赖。computed 一算改了 storestore 一变computed 依赖变了又重算重算又改 store……形成一个死循环。正确的做法是computed 只能做纯计算不能有副作用。所谓副作用就是对自身之外的响应式变量进行赋值、请求接口、写存储等操作。如果确实需要“输入时同步生成另一个字段”应该用watch或者事件回调import { ref, watch } from vue const companyName ref() const slug ref() watch(companyName, (val) { slug.value val.trim().toLowerCase().replace(/\s/g, -) })6.3 HMR 状态丢失和模块顶层副作用Vue 开发时有个恼人的问题改完代码热更新是生效了但组件状态丢了甚至页面白屏半天。排查时发现问题经常出在“模块顶层代码被执行了两遍”。Vue 的热更新机制是“保留组件实例、替换渲染逻辑”但如果模块顶层有副作用代码HMR 更新时会重新执行模块造成重复注册、重复执行请求等怪问题。比如// main.js console.log(module loaded) // 某些第三方库在模块顶层调用了初始化方法解决思路有三条第一模块顶层只声明不执行把初始化动作挪到组件生命周期或某些钩子里第二如果第三方库必须在模块顶层初始化检查有没有幂等性封装方案比如先判断是否已初始化第三遇到 HMR 异常先刷新页面确认问题是否依然存在如果刷新后消失大概率就是 HMR 与顶层副作用的兼容问题。6.4 排查链路的通用模板踩过太多坑之后我总结出了一套通用的响应式问题排查顺序对新手非常有帮助先确认数据变了没有。在对应位置打日志或断点看响应式变量是否真的被赋了新值再确认依赖被追踪到了没有。数据变了依赖数据的 computed、watch、模板有没有被通知到。如果没通知说明数据不在响应式系统内或者写法破坏了响应式链比如解构、绕过 ref 直接赋值最后确认是不是时序问题。数据变了、依赖也被通知了但视图还没更新——这种情况优先上nextTick处理如果还有问题打开 Vue Devtools 看实时组件树和数据流基本能定位到具体层级的失效点。关于 Vue.js 的学习我的核心体会就一句它的大部分难点不在 API 记不记得住而在于你有没有建立起“数据驱动”的心智模型。API 忘了查文档就行心智模型有了看什么组件都知道它内部大概是怎么运转的。带新人我也从不让对方背 API而是先问三个问题这个数据为什么要放进 ref模板里的这个表达式为什么每次渲染都会重算组件的这个状态从哪来、到哪去、被谁改过思路理清代码乱不到哪去。
