Vue 笔记写到第七篇这次不聊基础语法也不画响应式原理的图解重点全部放在工程实践里真正卡过人的地方组件通信方案怎么选、组合式函数怎么拆才不会拆出一堆烂代码、路由守卫的执行顺序为什么老和预期不一样、Pinia 到底管什么不该管什么还有性能优化里那些“知道但做不到”的细节。前六篇已经把入门语法、组件基础、路由和状态管理的初级用法过完了这一篇适合已经能独立写 Vue 页面、想在工程质量上再进一步的人也适合正在写自己 Vue 系列笔记的朋友拿来做对照参考。1. 组件通信方案别一上来就 provide/inject1.1 通信需求其实只有三种形态写了一段时间 Vue 之后组件通信这件事能排进“看似简单、实际最容易写乱”的前三名。刚入门的时候谁都是 props 往下传、emit 往上抛但随着页面层级变深有人开始把 provide/inject 当万能钥匙还有人把全局事件总线捡回来用最后代码变成一团麻。问题不在这些 API 本身而是没想清楚当前到底属于哪种通信场景。我把所有通信需求分成三种第一种是父子组件之间第二种是祖先组件和后辈组件之间第三种是没有任何父子关系、但需要共享同一份数据的平行组件。只要先归类方案基本就定了父子用 props 加 emitv-model 本质也是这套只是接口更友好跨层级多且数据相对稳定用 provide/inject真正需要多个页面或模块读写同一份会变化的状态直接交给 Pinia。顺序反过来十有八九要返工。1.2 provide/inject 的几个隐含限制provide/inject 在 Vue 3 里确实好用了不少能传响应式对象和函数但很多同学用着用着就忘了它的边界。它解决的是“从上层往下层传递依赖”的问题而不是“同步状态”的问题。父组件 provide 出来的 ref 或 reactive 对象子组件 inject 之后能感知变化但这种感知是单向弱耦合子组件改了 inject 进来的响应式对象父组件和兄弟组件不会收到任何通知机制除非你把数据源本身设计成带方法的仓库。另一个容易踩的坑是 provide 的值被“拍平”。如果你写的是provide(config, { theme: dark })这种普通对象字面量注入端拿到的其实只是一份引用后续父组件想整体替换这个对象子组件是感知不到的。稳妥做法是直接 provide 一个 ref 或 reactive 对象让变化发生在对象内部属性上而不是重新赋一个对象。我前期因为这个问题吃过几次亏主题切换怎么切都没反应排查半天才发现是重新赋值了对象而不是修改属性。1.3 我的选型顺序我现在有自己的默认规则能向上提升参数就提升参数父子之间能用 props/emit 说清的绝不上 provide/inject超过两层传递且中间组件不需要感知时才考虑 provide/inject一旦有多个页面或模块要读写同一份状态默认 Pinia。之前在模拟项目X里遇到过一套表单配置从页面顶层传给第二层、第三层中间两层只是透传。用 props 层层传每次改字段要动三处后来改成 provide 一个响应式配置对象中间层完全不用碰代码清爽很多。反过来购物车这种会被很多模块调用和修改的共享数据放进 provide 里就是自找麻烦交给 Pinia 才合适。组件通信没有银弹选型的核心始终是“先定位信息流的方向和范围再挑最短路径”。2. 组合式函数逻辑复用最容易写烂2.1 useXxx 的拆分边界Composition API 普及后很多人都掉进“把一切塞进组合式函数”的坑。函数本身没问题错的是拆分粒度。我见过有人把整页逻辑写进一个 usePage200 多行既管请求又管表单还管路由跳转说白了就是把 Options API 的 methods 换个地方待。我的拆分标准很朴素一个 useXxx 只解决一类问题。比如 useRequest 管请求状态loading、error、data、重试useTable 管表格的分页和筛选useFormValidate 管表单校验和错误提示。每个函数对外暴露的东西最好控制在三到五个以内超过就说明职责过重。拆的时候不用怕函数多组合式函数本来就是用来像搭积木一样拼逻辑的宁可拆细也不要一坨。给函数起名也别含糊usePage、useData 这种太泛了换成 useGoodsList 这种一眼能看出职责的名字团队里谁看都不会迷路。2.2 响应式丢失的三个隐蔽场景组合式函数里最常见的 bug 不是逻辑错误而是响应式偷偷失效。第一个场景是从 props 里解构const { list } props看着正常但 list 从此和 props.list 脱钩父组件更新后 list 还是旧值。正确做法是用computed(() props.list)或者toRefs(props)之后再解构。第二个场景是 reactive 对象被整体替换let state reactive({ count: 0 })里层某处写成state { count: state.count 1 }代理对象被换成普通对象视图再也不更新。第三个场景最隐蔽发生在组合式函数返回值被拆散时如果返回的是 reactive 对象外部用const { name } useSomething()解构出来name 就失去了响应性。我的习惯是组合式函数返回值全部用 ref 或 computed 包装好外部调用方也不做二次解构重赋值。这条规矩后来写进了团队约定之后“改了数据页面没反应”的报障基本绝迹。2.3 我的组织习惯一个功能一个目录除了函数内部分工文件组织也很影响维护体验。我现在习惯为每个业务功能块建一个独立目录里面放该功能的组合式函数和类型定义页面组件只负责组装。这样改某个功能时不会误伤其他功能。写完一个 useXxx我会顺手写两三行注释标明入参、返回的响应式数据和典型调用场景。代码是写给下一个维护者看的也可能是三个月后的自己多写这几行字能省下大量排查时间。组合式函数比 Options API 灵活太多灵活性意味着更需要约定否则每个人都能写出不同结构的“标准答案”。3. 路由进阶守卫顺序和拆包尺度的实践经验3.1 三类路由守卫执行顺序到底怎么排用 Vue Router 写权限控制很多人都在守卫顺序上栽过跟头。官方文档说得分散我把实际验证过的执行顺序整理成表阶段守卫类型触发时机1旧组件离开守卫导航开始旧页面组件内部先执行2全局前置守卫旧组件离开守卫结束后执行3路由级前置守卫目标路由配置里的 beforeEnter 执行4组件内进入守卫新页面组件的 beforeRouteEnter 执行5组件内路由更新守卫路由参数变化但组件复用时触发6全局解析守卫所有前置守卫都通过后执行7全局后置守卫导航确认后执行适合埋点和标题更新这张表最实用的地方在于权限校验放全局 beforeEach 一般没错但如果需要在离开页面时清理状态要知道旧组件的离开守卫其实最先执行。还有一类高频坑是“同一个组件在不同路由间切换”比如 /user/1 跳到 /user/2beforeRouteEnter 不会重新触发要处理的是 beforeRouteUpdate 或 watch 路由参数不然页面内容永远停在第一个人的数据上。3.2 懒加载的拆包尺度懒加载大家都知道写() import(/views/xxx.vue)但拆包颗粒度很多人没概念。有人整页所有路由都写成一个动态 import一个 chunk 几 MB也有人每个小组件单独拆浏览器请求数直接翻倍。我自己的经验是以页面级为拆包基本单位公共依赖单独打包业务代码按页面拆成中等大小 chunk单个控制在 200KB 以内比较舒服。用webpackChunkName给 chunk 起名排查网络请求时一眼能看出是哪个页面。拆包不是越细越好要的是加载速度和请求数量之间的平衡能踩油门也能踩刹车但别一脚踩到底。3.3 滚动行为与页面缓存的搭配列表页跳详情页再返回滚动位置能不能恢复直接影响体验。Vue Router 的 scrollBehavior 能拿到 savedPosition配合 keep-alive 缓存页面可以复用列表状态。注意用了 keep-alive 后组件初始化只走一次后续进入走 activated 而不是 mounted。如果数据加载写在 mounted第二次进入会看到旧数据。我把数据刷新和滚动位置恢复都放在 activated 里同时用 include 白名单精确控制哪些页面缓存避免所有页面都堆在内存里。4. Pinia 状态管理管什么、不管什么4.1 Store 里的数据边界Pinia 比 Vuex 轻但轻不代表可以乱放。我见过很多项目把组件本地的状态硬塞进 storestore 越来越大改一个页面要查十几个文件。判断一个状态该不该进 store我问三个问题是否被两个以上无关组件使用是否需要在路由跳转后仍然保留是否会被多个页面同时写入只要有一个答案是“是”就值得进 store否则留在组件本地。另一个原则是“能算的就不要存”。比如用户 store 里存了原始用户对象但“是否登录”“昵称简称”这种派生值完全可以在组件里用 computed 算出来没必要在 store 里再维护一份副本。少一份副本就少一个不同步的机会。数据边界越清晰跨模块开发的冲突就越少这个经验在多人协作的项目里尤其值钱。4.2 setup 写法下的 store 组织Vue 3 的 Pinia 有 Options 写法和 setup 写法我现在几乎全面转向 setup 写法。setup 写法更像组合式函数可以在 store 里定义 ref 状态、函数和 computed还能拿别的 store 做联动。举个例子export const useUserStore defineStore(user, () { const profile refUser | null(null) const isLoggedIn computed(() profile.value ! null) async function fetchProfile() { profile.value await request.get(/me) } return { profile, isLoggedIn, fetchProfile } })这样写的好处是类型推导自然状态和逻辑放在一起读起来和组合式函数没区别。要注意别在 store 里放 UI 组件实例或 DOM 引用既不能序列化又容易造成内存泄漏。store 的定位是“业务逻辑的收容所”不是“所有东西的仓库”。4.3 持久化的几种落地方式用户信息、主题偏好这类状态需要持久化。最简单是手动 watch store 里的字段配合 localStorage但 deep watch 有序列化开销Date、Map 这类复杂类型直接 JSON.stringify 会出问题。更省心的是用一个小插件统一封装持久化逻辑监听需要持久化的字段集合写入时做一层可逆转换读取时再解析。两种方式都要注意持久化的 key 要带项目前缀避免和同域名下其他应用冲突页面加载时读取顺序要固定否则会出现“刷新白屏、再刷一次才正常”的诡异现象。这个坑我踩过不止一次都怪当时没把“读缓存”和“拉接口”的时序理清楚。持久化不是必需品能用服务端存的尽量别丢前端一份前端只存“用户偏好”和“会话痕迹”这类真正离开本地就没意义的东西。5. 性能优化渲染频率和数据体积两手抓5.1 渲染频率先搞清楚组件为什么重新渲染Vue 的响应式系统挡掉了大部分无意义更新但项目一复杂还是会有“明明没改数据页面却一直跳动”的情况。排查渲染频率我习惯先打开 Vue Devtools 的组件树配合性能面板观察哪个组件在频繁 update。常见原因几类props 每次传入新对象模板里内联:listgetList()函数每次执行都返回新数组触发子组件更新、v-for 的 key 用 index 导致列表复用错乱、父组件一个响应式状态被多个不相关子组件依赖。对象和函数问题用 computed 或常量提前算出稳定引用就能解决key 的问题记一句话列表顺序会变就用业务 id不会变才考虑 index。5.2 数据体积列表、图片与按需加载渲染频率再低数据量太大也一样卡。图片用量大的页面要懒加载长列表要虚拟滚动或分页一次性拿几千条数据塞进页面的做法只适合极小的内部项目。图片懒加载我还想说一句很多项目直接引第三方库但原生loadinglazy属性已经覆盖大部分常见场景能少一个依赖就少一个依赖。长列表不想引虚拟滚动库的可以先按每屏数量做窗口切片配合滚动事件更新可视范围中等规模的列表完全够用。能减少的数据量就减少能延后的加载就延后这两句话能解决八成以上的性能问题。5.3 一个小页面的优化实录之前做一个筛选列表页三万多条数据全部渲染滚动一卡一卡的。优化三步走第一步接口改成按页码加载配合“已加载总条数”做累加不追求一次全量第二步列表项里的耗时计算比如状态文案映射、金额格式化全部用 computed 缓存避免每帧重复计算第三步图片换懒加载加渐进占位。三步做完首屏渲染从两千多毫秒降到六百毫秒以内滚动也顺畅了。性能优化不需要一上来就上高大上的方案逐层排查数据来源和渲染链路往往收获最大。6. 报错排查与调试技巧6.1 常见报错速查写 Vue 项目久了会碰到一批高频报错整理成速查表报错特征常见原因处理建议render 期间提示属性未定义变量名拼错或从 props 解构导致响应式丢失检查模板变量与 setup 返回项拼写Cannot read properties of undefined数据没加载完就访问数组/对象属性v-for 没做空态兜底加 v-if 或默认空数组Invalid vnode type动态组件绑定了 undefined或异步组件加载失败检查 defineAsyncComponent 导入路径Maximum call stack size exceeded响应式对象内部直接或间接引用自身检查 store 或 computed 的回环依赖6.2 调试的实用手段除了看控制台我调试 Vue 组件最常用的三招。第一招是 Vue Devtools不只是看状态还要学会看时间线面板和组件更新频率定位渲染瓶颈很好用。第二招是在可疑代码里加console.trace()或直接debugger配合浏览器调用栈看清是谁触发了这次更新。第三招是全局配置app.config.errorHandler把组件渲染和生命周期里的未捕获错误统一收集开发环境打 console.error生产环境走错误上报接口线上问题不会一头雾水。还有个小技巧在 store 里用$subscribe监听状态变化能快速定位是哪段业务代码改了共享状态。7. 边写笔记形成的三个习惯写这系列笔记的同时我也给自己立了几个规矩分享出来供参考。第一个习惯是每学一个 API先想清楚它适合解决什么问题、不适合解决什么问题然后写进笔记对应章节的“适用边界”里。这样做之后很多方案纠结直接消失因为边界已经提前划好了。第二个习惯是单独维护一份“踩坑记录”按“现象、原因、解决方式、涉及版本”四列整理。第三次遇到同一个报错时花十秒翻文档省下半小时重新排查。第三个习惯是写代码前先花两分钟画一下信息流谁的数据从哪来、谁在改它、改完谁会用到。这件事看起来慢实际是在给组件通信、状态管理、性能优化这三个大坑提前铺路。第七篇笔记写到这里我最深的体会是Vue 的核心 API 学起来不难难的是在真实项目里做取舍。这些问题没有标准答案但每次先想清楚需求再选工具基本不会跑偏。