跳到主要内容

Vue 2 到 Vue 3 的过渡

这篇更适合放在升级视角下看。它关心的不是“Vue 2 里有哪些 API”，而是一个典型 Vue 2 项目迁到 Vue 3 时，哪些地方最容易卡住。

最先感受到的变化​

1. 组件组织方式变了​

Vue 2 的主线是 Options API，Vue 3 虽然仍然支持它，但项目主流写法已经逐步转到 Composition API 和 <script setup>。

2. 响应式底层变了​

Vue 2 基于 Object.defineProperty，Vue 3 改成 Proxy。这会影响：

  • 对象和数组的追踪方式
  • 某些历史兼容写法
  • 自定义封装和底层理解

3. 一批写法已经不再推荐继续沿用​

例如：

  • 大量 mixin
  • 过重的 this 依赖
  • 组件内部逻辑按 data / methods / computed 机械分区

升级时最常见的几类任务​

指令和模板写法复核​

Vue 2 的很多指令写法仍然能用，但升级时更值得检查的是：业务是否还依赖历史模式，还是已经可以顺手把组件结构一起收掉。

组件通信和 v-model​

Vue 3 对 v-model 的约定更统一。组件库、自定义输入组件、多字段联动组件都需要额外看一眼。

生命周期对照​

常见对照关系：

  • beforeDestroy -> beforeUnmount
  • destroyed -> unmounted

真正更重要的是，很多副作用逻辑会改写到组合式钩子里。

自定义指令​

自定义指令仍然存在，但升级时要重新确认生命周期钩子和行为约定，不要直接把老代码无脑平移。

迁移时最值得先处理什么​

  • 工程环境和依赖基线
  • 路由和状态管理版本
  • 组件写法的主线选择
  • v-model 和双向绑定约定
  • SSR / Hydration 边界

keep-alive​

keep-alive 在 Vue 2 和 Vue 3 里都还重要，尤其在列表页、Tab 容器、动态组件切换这类场景里。

迁移时最值得确认的是两件事：

  • 组件缓存是否仍然符合业务预期
  • activated / deactivated 相关副作用是否已经迁到新的组合式写法里

如果项目里依赖页面缓存来保留表单状态、滚动位置或查询条件，这一块最好单独回归，不要只看页面能不能正常显示。

一个更现实的迁移顺序​

  1. 先把构建工具、依赖和工程基线理顺
  2. 再处理生态层：路由、状态管理、组件库
  3. 最后再逐步把复杂组件迁到 Composition API 或 <script setup>

很多项目的问题，不在于 Vue 3 本身，而在于升级时把“框架版本切换”和“整套代码风格重构”捆得太紧。拆开做，通常会稳很多。