企业官网建设流程全解析

前几天帮一个朋友看项目，他吭哧吭哧把老后台从 Vue 2 往 Vue 3 迁，结果光在依赖上就卡了两天：vuex 还是 3.x，vue-router 还是 3.x，组件库文档翻得人头皮发麻。最要命的是，团队里不少人对 Vue 3 的认知还停留在“版本号升了一位、语法差不多”这个层面，觉得升级框架就是改改 import 的事。真正跑起来才发现，Vue 3 不光是底层核心机制换了一套，连旁边的生态工具链也几乎洗了一遍牌：Vite 替代了 Vue CLI，Pinia 替代了 Vuex，<script setup>替代了一堆 Options API 写法，路由和状态管理的 API 全是新的。这篇文章我想把 Vue 3 的生态系统从头到尾串一遍——响应式系统为什么重写、组合式 API 到底解决什么问题、编译优化快在哪儿、以及 Vite、Pinia、Nuxt 这些核心工具链现在该怎么选型。无论你是刚准备上手的新人，还是正带着老项目写迁移方案的同学，这篇应该都能给你一个相对完整的图景。

1. 先扒底层：Vue 3 的三大重构到底动了什么

很多人看 Vue 3 的第一印象是：“哦，多了个组合式 API，能写函数式了。”但组合式 API 只是水面上的冰山一角。真正决定生态面貌的，是底下三块硬骨头——响应式机制重写、渲染器与编译器解耦、全局 API 重构。这三件事单独拆开看都不复杂，但组合在一起，就导致了你不能再拿 Vue 2 时代的那套工具链和心智模型来写 Vue 3 项目。

1.1 响应式从“登记属性”变成“代理对象”

Vue 2 的响应式方案你应该不陌生：初始化时遍历 data 里的每个属性，用Object.defineProperty把它们全部转成 getter/setter。这个方案最大的问题在于“必须提前知道要监听哪些属性”——对象新增一个属性不是响应式的，数组通过下标赋值监听不到，深层嵌套对象首屏渲染就要递归遍历，性能开销不小。为了补漏，Vue 2 还被迫重写了数组的push、pop等七个方法。

Vue 3 换成Proxy之后，整个逻辑完全变了。Proxy代理的是对象本身，不管你往里加属性、删属性、还是改数组下标，都能被拦截到。打个比方：defineProperty像搬家前给每件家具贴上标签、登记在账本上，之后你突然买了一把新椅子，账本不知道；Proxy则像在房间门口装了一个安检门，任何你带进房间的东西都会过一遍检查。这也正是 Vue 3 里“新增对象属性但视图不更新”这个 Vue 2 时代的老大难基本消失的根本原因。

性能上还有一个容易被忽略的点：Vue 3 的响应式代理是惰性的。对象没有被读取到的那一层，不会立刻被递归代理，而是等真正访问到那一层才做转换。换句话说，一个巨大但只浅层使用的对象，不会像 Vue 2 那样在初始化时就全部递归一遍。很多文章说“Vue 3 更快是因为 Proxy 比 defineProperty 快”，这个说法其实不太准确——就单次调用而言 Proxy 的开销并不小。真正带来收益的，是惰性代理省掉的初始递归、以及优化后更精准的依赖追踪。这也是理解后面第 3 章“响应式内幕”的一个基础认知。

1.2 渲染器与编译器的解耦带来了什么

Vue 3 的源码层面分成了多个独立包，其中最核心的拆分是reactivity、runtime-core、compiler-core。编译器负责把模板编译成优化过的渲染函数，渲染器负责把 vnode 映射到真实 DOM。这个拆分的直接好处是可以自定义渲染器——同一套响应式和组件调度逻辑，可以渲染到 Canvas、WebGL、甚至自定义的终端界面。

更实际的意义在架构层面：由于依赖追踪被单独抽成@vue/reactivity，你甚至可以脱离框架单独使用这套响应式能力。我见过有人在小项目里只用@vue/reactivity做状态管理，连 Vue 都没引入。这个包被拆得足够干净，反倒让 Vue 生态里像 Pinia 这样的状态库有了更轻量、更清晰的底层基础。

很多人问 Vue 3 为什么快，其实答案不是单一的技术点，而是一套组合：编译器做静态提升和动态节点标记，运行时通过 Block Tree 缩小 diff 范围，响应式系统让组件只在自己依赖改变时才重新渲染。三者互相配合，任何一个单独拎出来都谈不上革命，组装起来才是真正的性能来源。后面第 4 章我会单独展开编译优化那段，因为它是工具链升级的地基。

1.3 全局 API 重构，才是生态洗牌的根本原因

Vue 2 时代，全局能力都挂在Vue这个构造函数上：Vue.use()、Vue.prototype.$http、Vue.component()、new Vue()。Vue 3 把这些全部统一挪到了应用实例上：createApp().use()、app.config.globalProperties、app.component()。这个变化在官方迁移文档里写得很清楚，但它带来的连锁反应远超想象——生态里几乎所有 UI 组件库、第三方插件、工具函数库，只要内部依赖了 Vue 2 的全局 API，就必须重写或者大幅改造。

这也是为什么 Element Plus、Ant Design Vue 2.x 这些组件库会有那么大的破坏性升级。说白了，不是这些库想搞破坏性变更，而是框架底层的“挂载方式”变了，老库不改就没法跑。理解这层因果之后，你就不会再问“为什么一个个库突然都要改 API”这种问题了——不是大家约好了一起不兼容，而是地基换了，上面的房子都得跟着重建。

2. 组合式 API：一场代码组织方式的“重排”

如果只选一个 Vue 3 最直观的变化，那肯定是组合式 API。我特别反感一种说法：“组合式 API 就是给 Vue 加了 React Hooks 类似的写法。”这话只讲对了一半。Vue 的组合式 API 在设计上确实参考了 React Hooks 的思路，但它是在 Vue 自己的响应式系统上生长的，它不是“抄”，而是顺着 Vue 的数据流自然长出来的一种代码组织方式。

2.1 Options API 在复杂组件里的尴尬

给你还原一个典型后台组件的 Vue 2 写法。假设一个用户管理页面，里面有接口数据、搜索条件、分页、当前选中项、批量操作。在 Options API 里，这些逻辑会被强制拆成 data、computed、methods、watch 四块。数据挤在一个 data 对象里，方法全排在一个 methods 大对象里。

问题就出来了：一个页面的业务逻辑，物理上被拆成了四个“大仓库”，你想看“搜索”这条业务链路，需要在 data 里找到keyword，在 methods 里找到handleSearch，在 watch 里找到监听，在 computed 里找到过滤结果——来回跳。等组件写到几百行，每个块都几十个成员的时候，最常遇到的困惑就是“这个 data 到底被哪个方法改过”“这个方法是给哪个功能用的”。不是你不能写，是维护成本太高了。

组合式 API 的思路是把“同一件事”相关的状态和方法写在一起。搜索条件、监听、过滤计算、加载方法作为一个整体放一个函数区域，分页作为一个整体放另一个区域。组件再大，也是由几个内聚的“业务块”拼起来的，每个块自己闭环。

2.2<script setup>和组合式函数的实际写法

Vue 3.2 之后，官方推荐直接采用<script setup>语法，这也是现在 create-vue 脚手架的默认写法。它最大的好处是省掉了顶层 return，import 进来的东西直接用，组件里的变量和函数自动暴露到模板。以前写setup()函数还要手动return { ... }，现在整个样板代码被压缩掉了。

代码层面，你写的组合式逻辑可以提到组件外部，形成独立的组合式函数。比如封装一个带防抖的搜索功能：

<script setup> import { ref, watch } from 'vue' import { fetchList } from '@/api/user' const keyword = ref('') const list = ref([]) const loading = ref(false) watch(keyword, (val) => { // 稍作简化，实际项目建议把请求逻辑拆成独立函数 loading.value = true fetchList({ keyword: val }).then((res) => { list.value = res.data loading.value = false }) }) </script>

这段逻辑如果还放在 Options API 里，拆成四块也说得通。但组合式 API 真正的价值是“跨组件复用”。你可以把上面这段搜索逻辑整体抽到一个文件里，变成一个useSearchList函数，两个组件各拿一个实例。这个做成组合式函数的复用能力，是 mixin 完全比不了的。

2.3 mixin 的坑和组合式函数的优势对比

我见过太多 Vue 2 项目，最后被 mixin 折磨得要死。mixin 的问题有三个：第一，命名冲突——两个 mixin 都想用data这个变量名，谁赢完全看合并顺序，出了 bug 极难排查；第二，来源不透明——模板里一个方法，你根本不知道它来自哪个 mixin、哪个组件定义；第三，组合逻辑没法参数化——同一个 mixin 想在两个组件里用不同的配置，只能靠 props 或者继承，别扭得不行。

组合式函数直接解决了这三个问题：命名冲突变成了函数作用域的普通变量遮蔽，肉眼可见；来源就是一个普通 import，路径清清楚楚；每个函数接收参数、返回被拆解的状态，天然支持差异化配置。我把这套写法推荐给团队里的人之后，大家的反馈很一致：单个组件确实清爽了，跨组件复用也敢写了，而不是每次想复用都要纠结“要不要抽 mixin”。

2.4 这一章必须提醒的几个小坑

写组合式 API 的时候，有几个细节特别容易踩，我自己的项目里都遇到过，网上教程倒是不常提：

第一，reactive的对象不要直接解构，否则响应性就丢了。举个例子：

const state = reactive({ count: 0 }) // 直接解构，count 就变成普通数字了 const { count } = state count++ // 视图不会更新

正确做法是用toRefs包一层，或者干脆用ref。

第二，script setup里 props 的解构问题。从props里取字段直接解构同样会丢响应性，建议始终使用props.xxx或toRef(props, 'xxx')。这个坑在 TypeScript 项目中出现的频率很高，因为很多人习惯了结构体解构。

第三，响应式大对象的性能。图表配置、地图数据这类体积大但不需要深层响应的数据，建议用markRaw标记，或者放进shallowRef里。如果你把一个几千行的静态配置对象扔进 reactive，Vue 会为它建立一整套代理和依赖记录——这部分开销完全没有必要。后面第 3 章讲完响应式原理，你会对这个建议有更直观的理解。

3. 响应式系统内幕：值得花二十分钟搞清楚的东西

Vue 3 的响应式系统是整个框架最值得研究的底层模块，也是面试高频题。但我的建议是，别单纯为了面试去背“Proxy 和 defineProperty 的区别”，因为真正影响你日常开发质量的，是依赖收集（track）和触发更新（trigger）这套机制。

3.1 依赖收集的完整链路

Vue 3 的响应式核心只有几个关键函数：reactive用于把对象变成 Proxy，effect用于注册副作用，track在读取响应式属性时收集依赖，trigger在修改时重新执行相关副作用。整个机制可以这样理解：当一个副作用函数执行时读取了某个响应式属性，这个副作用就会被记录到该属性的依赖集合里；下次这个属性变化，依赖集合里的所有副作用会被重新执行。

内部数据结构是WeakMap套Map套Set：WeakMap的 key 是源对象，value 是一个Map；这个Map的 key 是属性名，value 是一个Set，里面存了所有依赖该属性的 effect。为什么用WeakMap而不是Map？因为WeakMap的 key 是弱引用，源对象被垃圾回收后，对应的依赖记录也会自动释放，避免了手动清理的麻烦。这个设计很优雅，也是很多人忽略的细节。

3.2 ref 是怎么“伪装”成响应式的

ref的实现逻辑非常直白——它内部创建一个对象，这个对象的value属性被设置成 getter/setter。读取value时调用track收集依赖，设置value时调用trigger触发更新。这也是为什么在 JavaScript 里使用ref必须写成count.value，而在模板中可以直接写{{ count }}——模板编译器帮你做了自动解包。

这个设计是为了让原始类型的值也能被追踪。reactive只能处理对象，原始值加一层包装之后，就变成一个对象了，自然也能进入依赖追踪体系。这背后没有高深的东西，理解了 getter/setter 就够了。

3.3 落实到日常开发的三个建议

我先给一个简化版的响应式原理想法：数据变化要触发视图更新，前提是视图渲染时读到了这个数据。这个链路对实际开发的指导意义非常大：

建议一：只对需要响应的数据做响应式代理。大到几乎没有变化的静态配置，直接markRaw标记掉，省掉无谓的代理开销。我做过一个图表项目，把ECharts的 option 全部markRaw之后，组件渲染性能没有退化，交互反而更流畅——因为 Vue 不用每帧代理追踪几百个配置字段了。

建议二：频繁更新但结构不深的状态，用shallowRef。比如一个埋点上报对象，每次更新都是整体替换，没有必要深度代理它内部的字段，shallowRef只跟踪一层就够用。

建议三：不要在响应式对象里引用第三方类实例然后随意操作。有些原生对象属性很多，被 Proxy 代理后可能出现意料之外的问题，必要时用markRaw把第三方实例排除在代理之外。

这三点不是从源码里背出来的，是我自己从项目异常中排查出来的经验——一个几千行的配置对象进 reactive 之后，页面交互肉眼可见地变卡，排查来排查去，最后发现是代理开销的问题。

4. 编译优化与运行时设计：Vue 3 的快到底快在哪

如果你只记得一个结论，我希望是这句话：Vue 3 的渲染性能提升，主要是“编译时静态分析”和“运行时精细 diff”共同作用的结果，而不是单纯因为响应式换成了 Proxy。Vue 3 的编译器会把模板翻译成一个高度优化的渲染函数，同时在编译阶段就标注出哪些地方是动态的。

4.1 静态提升、事件缓存与 PatchFlag

先看一个简单模板：

<template> <div> <span>用户名：{{ name }}</span> <button @click="handleClick">提交</button> </div> </template>

Vue 2 在重渲染时，会重新创建整棵 vnode 树，然后和旧树做全量 diff。Vue 3 的编译器会做几件事优化：静态节点（没有动态绑定的部分）会被提升到渲染函数之外，首次创建后直接复用，不再重复生成；事件处理器是稳定函数，编译器会用缓存包装，避免每次渲染都产生新的函数引用，从而减少子组件因为 props 变化而触发的无意义更新；动态绑定会标记PatchFlag，比如TEXT表示只更新文本内容，PROPS表示只需要更新某些属性。

有这些标记之后，运行时 diff 的成本大幅下降——渲染器不需要再遍历整个树的每一个属性去判断有没有变化，而是直接定位到需要更新的节点和属性。这就是“靶向更新”。

4.2 Block Tree 和动态收集机制

Vue 3 的另一个关键优化是 Block Tree。编译器会把模板结构编译成一个 block 树结构，每个 block 内部维护一个动态节点数组，把所有带PatchFlag的节点都收集到这个数组里。运行时只需要对比这个动态节点数组即可，静态部分完全不 diff。模板越大，这种割裂效果越明显。

用大白话说：Vue 2 的 diff 是对比整棵树，Vue 3 的 diff 是对比一张“动态清单”。清单上的节点就是这么几个，变没变一眼扫过去就行。这里有个值得注意的边界：不要写大量动态嵌套结构或者频繁切换v-if分支，因为这会让编译器难以做静态分析和 Block 提取，diff 开销就会变大。官方文档里一直强调“保持模板结构稳定”，背后的原因就在这里。

4.3 Vue 3 没有 Fiber，但为什么也不需要

React 有 Fiber 架构，Vue 3 没有。为什么 Vue 3 不需要引入类似机制？核心原因是 Vue 3 的更新粒度太小了：每个组件都有自己的响应式依赖，数据变化时，Vue 能精确定位到哪个组件的哪个渲染函数依赖了这个数据，从而直接触发那个组件的更新。跨组件更新也能通过effect的调度机制协同处理，没有必要把渲染工作切片化。这就像反恐行动：React 是调度中心把任务拆成很多小片分批派发，Vue 是情报部门已经精确定位了嫌疑人在哪栋楼哪层哪间房，直接上门就行。Vue 3 不是没有 diff，它是用更精准的方式让 diff 变得无关紧要。

4.4 SFC 编译器是工具链升级的支点

这套编译优化能在实际开发中生效，依赖的是新版的 SFC 编译器@vue/compiler-sfc。日常开发不直接调它，但它被 Vite 插件自动调用了。你写的<script setup>语法会被编译成常规的 setup 函数，模板部分会被编译成带 PatchFlag 的渲染函数。正因为编译器做了这些静态分析，<script setup>能推导出组件 props、emit 的类型信息，给 TypeScript 工具链提供了非常友好的支持。这也就解释了为什么整个 Vue 3 工具链会发生迁移——Vite 的按需编译、Vitest 的组件测试、Nuxt 的文件路由，所有这些都建立在新编译器的工作之上。

5. 工具链选型：Vite、Pinia、Router 以及其他，怎么选才不绕路

聊到工具链，先澄清一个概念。在不同领域，“工具链”的所指差别很大——嵌入式领域提工具链，往往说的是 musl 库、交叉编译器那一套；但在前端生态里，工具链就是围绕框架的整套开发基建，包括构建工具、路由、状态管理、测试、脚手架、以及 SSR 框架。Vue 3 生态里，这些几乎全部重选了一遍。这一章我按项目类型给出选型参考，并详细拆解每个工具为什么是它。

5.1 构建工具：Vite 为什么是默认答案

Vue CLI 曾经是 Webpack 时代 Vue 项目的官方推荐，但现在新项目默认就是 Vite，create-vue脚手架直接用 Vite 做底层。Vite 开发服务器最直观的优势就是快：它不需要像 Webpack 那样从入口递归打包整个依赖图，而是直接利用浏览器原生 ESM，按模块请求按需加载。冷启动一个大型项目，Webpack 可能要等十秒以上，Vite 基本一两秒就绪。

Vite 还做了依赖预构建，用 esbuild 把 node_modules 中 CommonJS 格式的依赖转成 ESM 并缓存。esbuild 因为是 Go 写的，转换速度比传统 JS 打包工具快一个数量级。生产构建默认走 Rollup，加上@vitejs/plugin-vue处理 SFC 编译，这个组合在目前的前端构建工具里非常均衡。选型建议简单直接：除非项目有不可替代的 Webpack 插件需求，否则新项目无脑选 Vite。

5.2 状态管理、路由、请求层：一套新的标配组合

先看状态管理。Vuex 4 在 Vue 3 生态里还活着，但新项目现在几乎都用 Pinia。Pinia 的优势非常实际：没有 mutation，改 state 直接赋值操作；store 定义可以用 setup 风格，和组合式 API 保持一致；TypeScript 类型推导完善；自动支持 store 之间的嵌套调用。我实际用下来的感受是，Pinia 把 Vuex 里最折磨人的 namespace 和 getter 心智负担去掉了，写起来像在写普通模块，但状态响应性全程在线。

再看路由。Vue Router 4 的变化主要是 API 从new Router()变成createRouter()+createWebHistory()，meta字段的类型可以使用 TypeScript 模块扩展来定义，鼓励在<script setup>里用useRoute、useRouter组合式函数而不是靠this.$route。如果你的项目要从 Vue 2 迁移，路由写法几乎是必改项。

请求层依然是 axios 主打，但真正流行的用法不是把它挂在Vue.prototype上，而是写一个useRequest组合式函数。加载状态、错误状态、返回数据统一封装在一个函数里，每个组件按需调用，比全局挂载干净太多。我给团队定的规范就是：所有数据请求必须走组合式函数封装，禁止在组件目录里散落裸的 axios 调用。

下面这张表我按项目类型整理了推荐组合，方便直接抄作业：

5.3 全栈框架与周边生态

Nuxt 3 出来之后，Vue 的 SSR 体验发生了很大的变化。过去要自己搭 express + vue-server-renderer，处理路由匹配、请求数据预取、状态管理在服务端和客户端之间同步，代码量不小。Nuxt 把这些全部内置了：文件系统路由、自动导入、服务端数据拉取、构建工具默认 Vite。想做 SEO 或者需要一套完整全栈解决方案，Nuxt 基本是标准答案。Nuxt 4 继续演进，使用上保持稳定，新项目建议直接按官方最新版本走。

测试领域，Vitest 是 Vite 原生测试框架，和 Vite 共用一份配置文件，跑单测和组件测试非常顺手。如果项目已经用了 Vite，我不太建议再去引入 Jest——配置层面对齐成本高，迁移到 Vitest 反而是更省事的选择。VueUse 则是组合式函数工具集的集大成者，useDebounceFn、useLocalStorage、useFavicon、useIntersectionObserver这些高频工具有了统一封装，大量减少自研工具代码。我是很推荐的，几乎每个实际项目都能用上其中十几个函数。

5.4 工具链里容易忽略的 env 细节

从 Vue CLI 切到 Vite 的团队，最常踩的一个坑是环境变量。Vue CLI 时代写process.env.VUE_APP_API_BASE，到了 Vite 全变了：需要用import.meta.env.VITE_API_BASE。而且 Vite 默认只把带有VITE_前缀的变量暴露给客户端代码，其他环境变量全部屏蔽。这个设计是刻意的——防止你一不小心把服务器密钥塞进打包产物。实践中注意import.meta.env.MODE（当前模式）、.env.development和.env.production的加载优先级就可以。我第一次迁移时没注意前缀，页面请求全打到undefined上了，查了好久才意识到是环境变量名的问题。这里提醒一下：工具链升级后，很多看似无关的小细节都是迁移的坑，环境变量是其中最容易“无声失败”的一个。

6. 从 Vue 2 迁移：一张避坑清单，和一些真实教训

这章写给正在做迁移决策的人。我的总体判断是：能不能迁，先不要看 Vue 3 本身，要看你的依赖链条里那些第三方库是否已经全部适配 Vue 3。框架升级是容易的，难的是依赖生态整体跟进。

6.1 哪些地方会最先爆炸

老项目迁移时会先炸掉的地方，通常在这么几类：

首先是全局 API。new Vue()改成createApp().mount()是最基础的，但真正的雷在Vue.prototype上。以前在Vue.prototype上挂$http、$message这种全局变量，现在要去app.config.globalProperties挂。如果你有一个请求封装依赖全局实例，迁移时很容易出现“实例还没创建、插件已经运行”的顺序问题。我见过几次Cannot read properties of undefined就是这种原因。

其次是 UI 组件库。Element UI 必须换成 Element Plus，Ant Design Vue 必须升级到 2.x 版本。这些库内部大量依赖 Vue 2 的全局 API，不升级基本活不下来。很多项目卡在这一步——组件库不更新，其他代码迁移得再好也跑不起来。所以我把组件库的适配情况放在迁移评估的第一步。

然后是路由和状态管理。Vue Router 4、Pinia 和 Vuex 3/4 的 API 差异很大，意味着相关代码几乎要重写。如果你的项目里状态管理写了大量 mutation 逻辑，迁移到 Pinia 时要做不小的结构调整。

6.2 渐进迁移的路线图

除非你确定整个项目可以先冻结版本，一起升级，否则我更推荐渐进式迁移。Vue 官方提供了@vue/compat兼容构建，它可以在 Vue 3 运行时里模拟 Vue 2 的不少行为，让老代码继续以 Options API 的方式运行。迁移可以按四步走：

第一步，先把依赖整体升级到兼容态：Vue 3 +@vue/compat，UI 库换成适配 Vue 3 的版本，路由和状态管理对应升级。这一步不追求新写法，只求能编译、能跑起来。

第二步，处理掉所有全局 API 迁移问题：Vue.prototype、Vue.use、Vue.component等全部改为应用实例的写法。

第三步，组件代码逐步从 Options API 迁到组合式 API。我的建议是“改一个页面就彻底改一个页面”，不要在一个文件里混两套风格，否则维护成本会翻倍。

第四步，测试工具和构建工具同步升级：Vite 替换 Vue CLI，测试框架切到 Vitest，@vue/test-utils升到 2.x。

6.3 迁移过程中我印象最深的一个坑

说一个我遇到真事的例子。有一个老项目用的是自己封装的Vue.prototype.$request，内部从 Vue 的 options 里读取 baseURL 配置。迁移时我顺手把它放到globalProperties，但从createApp拿到应用实例后，又在安装插件前调用了请求封装，结果globalProperties还是空的，请求实例直接 undefined。这种问题教程里不会写，排查起来也没什么捷径——只能从调用时机、初始化顺序倒推。后来我强烈建议团队：所有请求依赖不要从全局对象拿配置，用单独模块或环境变量注入。组合式 API 时代，全局挂越来越少才是对的，工具链的迁移正好是一个清理“隐式全局依赖”的机会。

6.4 不迁也是一种选择

最后，如果你的项目依赖链里还有核心库没适配 Vue 3，比如某个行业特定的图表库、富文本编辑器只支持 Vue 2，那我的建议很直接：先别迁。Vue 3 再好，也架不住关键依赖拖后腿。判断标准很简单：项目里所有的 npm 依赖里，凡是要操作 DOM、要依赖 Vue 实例的库，全部检查一遍有没有 Vue 3 版本。适配齐了再谈迁移，否则就是给自己挖坑。我见过一个团队因为强迁，最后不得不临时推倒重写两个核心页面，代价比预期高得多。

一些最后的体会

说句实在话，Vue 3 生态给我最大的感受不是“API 变多了”，而是“整套体系终于统一了”。响应式的重写、组合式 API 的引入、编译器的现代化、Vite 作为构建标准的落位，这四件事本质上是一个方向：让 Vue 的代码更可组合、更可推导、更快。新工具链用起来之后，那种“写 Vue 2 时时不时被全局面板牵制”的感觉消失了，每个组件都像一个独立的黑盒，状态和逻辑的边界清晰可见。如果你正准备开始一个新项目，我真心建议别抱着 Vue 2 的学习路径不放：直接学<script setup>+ Pinia + Vite + Vue Router 4，你会发现这套组合的学习曲线远比想象中平滑。至于迁移，急不来，先跑通一个小页面、再清理掉那些隐式依赖，一步一个脚印，生态新老交替这件事，其实没有想象中那么吓人。