1. 石器时代没有框架的日子前端到底有多痛1.1 原生 JavaScript 的“原始生活”早年间做前端哪儿有什么框架概念。HTML 里随手塞几个script标签拿原生 JavaScript 操作 DOM改个文案都得小心翼翼 getElementById改完了还得操心这段代码在 IE6 里能不能跑。我印象最深的一件事是给一个表格加行靠的是拼字符串塞 innerHTML要拆掉一行又得一层一层找父节点 removeChild。代码写多了整个人就是 DOM 结构本构脑子里全是层级关系。更要命的是浏览器兼容性。Chrome 还没出生的年代IE 和 Netscape 各说各话同一个事件绑定的写法能差出一整套来。今天你要监听一个按钮点击可能得自己写个 addEvent 工具函数在里面判断 attachEvent 还是 addEventListener。这些重复造轮子的活儿就是前端的“石器时代”——不是不能干活是每件活儿都得从砍石头开始。那时候的团队里能背出一长串浏览器 hack 的人就是大家眼里的“大佬”。那个阶段其实也没有特别统一的解决方案。很多项目把 JS 当“小脚本”用页面主体靠服务端渲染前端只负责在表单验证和轮播图上蹦跶两下。但产品需求一多问题全暴露了页面状态散落在无数个全局变量里数据一变DOM 不同步调试全靠 console.log 和肉眼比对。最难受的场景是提交一个表单——你要在 submit 事件里把十几个字段的值挨个读出来组装成对象再手动校验、手动渲染错误提示一套流程下来代码又长又脆还不敢轻易动。1.2 jQuery把我们从重复劳动里捞出来的“那根棍子”2006 年 jQuery 一出来前端圈瞬间炸锅。$(...)选择器拿元素链式调用一把梭AJAX 请求一行搞定跨浏览器兼容性问题也基本被它摆平了。那时候的口号是 write less, do more我们是真的体会到了什么叫“生产力解放”。以前要写十几行的取元素加事件绑定换成 jQuery 就是$(#btn).on(click, fn)的事。但 jQuery 本质上是工具库不是框架。它把 DOM 操作封装得再漂亮还是没有帮你回答一个根本问题数据和界面之间的关系到底怎么维护页面简单时无所谓项目一大你依然要在 ajax 回调里手动更新一排 DOM 节点。维护状态的老大难jQuery 只能缓解不能根治。我们团队当时接过一个后台管理系统全是 jQuery 手写交互改一个数据源能把排查范围铺到几百行代码里去——那个痛苦我到现在还记得。1.3 后端模板模式的瓶颈其实在 jQuery 流行的同期很多项目也依赖后端模板渲染——PHP 的 include、Java 的 JSP、Python 的模板引擎都是服务端拼好 HTML 再吐给浏览器。这在页面以展示为主的时候很顺畅但一旦页面上出现大量用户交互、局部刷新、复杂表单联动来回整页刷新就变得又慢又呆服务器压力也跟着上去了。SPA单页应用的概念就是在那个时候抬头的——把渲染逻辑尽量搬到浏览器端让页面不再动不动整页刷新。但真要把整个应用的前端逻辑组织好就不能靠 jQuery 加字符串拼接硬扛必须有更高层级的抽象。需求推进着工具往前跑这就给第一代 MVVM 框架铺了路。2. 框架三国Angular、React、Vue 是怎么打起来的2.1 AngularJS 是开路先锋Angular 是自我革命2010 年 AngularJS 横空出世第一次让人看到“前端也能像后端一样有正经架构”。双向绑定、依赖注入、指令系统全是让人耳目一新的东西。尤其是双向绑定——数据一变视图跟着变视图变了数据也自动同步写表单逻辑简直像开了挂。当时我拿它做了一个后台项目确实爽改个 input 的值连手动取 DOM 都不用。但 AngularJS 的成也绑定、败也绑定scope 的继承机制和 watcher 数量过多时性能急剧下降而且概念庞杂学习曲线陡峭。后来 Google 推 Angular 2直接重写底层改用 TypeScript、组件化、AOT 编译连名字都去掉了 JS。这次革命的代价很大——老项目几乎等于推倒重来很多团队因此转向了别的阵营。Angular 到今天依然是企业级项目的可选方案但已经不是那个“人人争着学”的它了。2.2 React虚拟 DOM 与组件化的旗帜2013 年 React 开源带火了两个概念组件化和虚拟 DOM。它主张单向数据流配合 Flux/Redux 管理状态把“界面”彻底拆成可复用的组件树。虚拟 DOM 这个设计在当年的意义不光是性能优化更关键的是它把“操作 DOM”这件事抽象掉了——你只需描述界面长什么样怎么更新交给框架。这等于把前端从“手艺人”变成了“建筑师”。我用 React 写项目的最大感受是脑子得切换到“数据驱动视图”的频道不能再想着“点击之后我改哪个 DOM 节点”。这种思维转变对老前端来说不轻松但一旦转过弯来写复杂交互反而省心了。React 生态也因此迅速膨胀hooks 机制让函数组件一路封神到今天 React 依然是全球使用率最高的前端框架之一。2.3 Vue 2渐进式路线的胜利2014 年 Vue 诞生尤雨溪的设计哲学很明确渐进式框架。想要完整全家桶可以想要轻量搞个页面也能上手。Vue 2 最打动我的一点是它把 React 的组件思想、Angular 的指令模板揉在了一起又保留了 jQuery 时代开发者熟悉的模板语法——{{ }}插值、v-for、v-if学起来几乎没有心理门槛。Vue 2 的双向绑定用的是Object.defineProperty去劫持数据属性的 getter/setter。这个方案在当年够用组件规模变大后新增属性检测不到、数组索引变化监听不灵敏、大数据量对象性能吃力这些短板就慢慢浮出水面了。Vue 2 当然是里程碑式的成功但技术这东西不进则退不改底层后面的路越走越窄。2.4 Vue 3 为什么“非来不可”到了 2019 年前后前端领域的竞争格局已经很明确了React 有 hooksTypeScript 全面普及构建工具也进入下一轮迭代。Vue 2 如果不做根本性升级就会在性能和开发体验上被渐渐拉开。Vue 3 的“非来不可”其实可以从三个层面看第一层响应式系统必须换代。Object.defineProperty只能劫持已有属性对新增、删除属性无能为力数组原生的索引赋值也监听不了。换成 ES6 的 Proxy才能真正做到“全量拦截”。第二层逻辑复用需要更优的抽象。Vue 2 的 Options API 把代码按 data、methods、computed 等“选项”组织组件一变复杂同一个业务逻辑会被拆散到各个区块维护时来回翻文件。Composition API 就是为了解决这个痛点。第三层性能和体积要有质的提升。Vue 3 利用编译时更多静态信息做优化配合 Tree-shaking基础包体积比 Vue 2 小了不少渲染性能也明显更好。3. Vue 3 的核心技术拆解学了到底在学什么3.1 Composition API组织代码逻辑的新范式很多人听到 Composition API 的第一反应是“这不是抄 React hooks 吗”。从功能灵感上确实有交集但 Vue 3 的监听器、watchEffect、computed 这些设计有自己的一套体系跟 React hooks 的闭包规则完全不同。它解决的终极问题是同一块业务逻辑不再被拆散到 data、methods、watch 等不同选项里。举一个很典型的场景一个列表页面需要请求数据、处理筛选、监听路由参数变化、在组件卸载时清理定时器。用 Options API 写你得在 data 里放变量在 methods 里写函数在 computed 里写派生状态在 watch 里监听参数在 beforeDestroy 里清定时器——一个完整功能的代码被打散在五个区块里。而用setup语法你可以把数据、方法、侦听器、生命周期放在一起跟这个功能相关的代码一目了然。我在实际项目里最常用的是script setup语法。它比手写setup()函数返回对象还省事顶层变量直接就是模板里能用的绑定。组件导入即用不用再注册写起来干净利落。至于ref和reactive怎么选我个人的经验是基本类型用ref深层对象用reactive但如果你要在模板里解构、传参、或者给外面暴露状态还是统一用ref最省心——因为reactive的解构会丢失响应性这是个高频坑。3.2 响应式系统重构从 defineProperty 到 ProxyVue 2 的响应式简单说就是遍历对象的所有属性用Object.defineProperty改写它们的 getter 和 setter。这个方法有几个硬伤一是对象新增属性时没经过 setter不会触发视图更新所以 Vue 2 才提供了Vue.set这个补丁 API二是用索引给数组项赋值、修改数组长度都没法被监听三是一开始就要递归遍历整个对象数据量大时初始化就卡。Vue 3 换成 Proxy 之后整个响应式机制的根本规则变了。Proxy 劫持的是对象本身的操作不管你是新增属性、删除属性、取索引、改长度还是读某个嵌套对象的值都能拦截到。再加上惰性递归——只在你实际读取到那层数据时才做深层响应式——性能比 Vue 2 的全量递归好不少。顺手说一个踩坑点reactive代理的对象和原始对象用比较是false的。项目里有同事把reactive返回的对象塞进了watch的普通数组里结果怎么都不触发。正确的做法是watch监听reactive对象时直接传对象本身或者用 getter 返回需要的字段。这些不能靠猜得多看文档里的“侦听器”章节。3.3 编译优化静态提升、PatchFlags 与快速 diffVue 2 的虚拟 DOM 是全量 diff运行时很难知道哪些节点是静态的。Vue 3 的平台优势在于它有一个“编译时运行时”联手优化的过程。编译器会在编译阶段把模板里不变的静态节点提升到渲染函数之外不在每次更新时重复创建。动态绑定的节点会打上 PatchFlags 标记diff 时只比对有标记的节点。这带来的好处很直接同样的页面Vue 3 的 diff 工作量更小。再加上 Fragment 支持——组件可以有多个根节点不用像 Vue 2 那样必须包一个外层 div模板结构更清爽。这个改变看着小实际写组件的时候非常舒服尤其做列表布局时不想为了样式再包一层壳子。3.4 Vite开发体验的全面升级Vue 3 官方推荐配套 Vite很多人忽略了 Vite 本身就是“为什么值得学 Vue 3”的理由之一。Vite 基于原生 ESM 和 esbuild启动项目不用打包全部依赖按需加载文件模块首次启动速度和热更新速度都远远快于 Webpack 时代。我印象很深的是接手一个 Webpack 老项目启动要 40 秒改一行代码热更新等三四秒切到 Vite 之后冷启动基本一两秒热更新几乎是即时响应。这个开发体感的变化是写代码动力层面的提升。当然 Vite 也不是万能灵药。老项目里有些依赖不兼容原生 ESM 时你得在optimizeDeps里做预构建配置。生产构建默认用 Rollup个别极端场景的性能需要额外调优。但从零开始的新项目直接用 Vite 比 Webpack 配置省了九成的功夫。4. Vue 3 值得学的现实理由生态、协同与长期趋势4.1 生态现状Vue Router、Pinia、Nuxt 3 已经全员就位早两年大家犹豫要不要上 Vue 3很大原因是生态没跟上。到现在这个阶段这套顾虑基本可以放下了。Vue Router 4 支持了组合式 API 风格的路由用法可以在 setup 里直接拿useRoute和useRouterPinia 取代 Vuex 掌管状态管理API 设计非常轻——没有 mutation 那一层多余的仪式感TypeScript 支持也很顺手写起来比 Vuex 舒服太多。至于服务端渲染和全栈方案Nuxt 3 已经全面转向 Vue 3 和 Vite。如果你要做 SEO 友好的内容站或者想用一套技术栈同时搞定前端和后端接口Nuxt 3 已经能立起来了。Element Plus、Vant 这类常用 UI 组件库也早已完成 Vue 3 适配我在实际做中后台管理系统时Element Plus 配合 Vue 3 的体验已经很成熟。4.2 就业与团队协作的现实考量从就业角度看Vue 在国内的地位依然非常稳固。大量中后台系统、电商界面、企业内部工具都是 Vue 技术栈。虽然 React 的岗位也不少但很多公司招聘时 Vue 和 React 是并列要求的会 Vue 2 的人很多真正能把 Vue 3 的 Composition API 和调试响应式系统讲清楚的人反而稀缺——这就是机会。从团队协作的角度说Vue 3 对“不同水平的开发者在同一项目里协作”这件事比 React 要宽容。模板语法对后端转前端的同事非常友好setup 里也能按自己的习惯组织代码。我见过一个团队混着写 Options API 和 Composition API虽然风格不太统一但 Vue 3 允许 Options API 继续使用这在迁移期给了团队缓冲。一个有经验的负责人可以把新语法用在复杂页面给基础模块保留旧写法平滑过渡。4.3 学习成本对比Vue 3 是不是比 React 门槛更高很多人担心 Composition API 学习曲线。我的结论是Vue 3 的入门门槛仍低于 React。原因很朴素Vue 3 保留了模板语法HTML 部分跟着直觉走就行状态管理和组件通信都有明确的推荐路径而 React 的 JSX 函数式思维、hooks 的依赖数组规则、不可变数据的习惯需要一段适应期。Vue 3 的难点在“响应式系统的理解深度”——什么时候会触发更新、为什么 ref 赋值后要 .value、watch 和 watchEffect 的区别是什么。这些问题只要用真实项目练一遍是不难吃透的。5. 实战避坑指南从 Vue 2 迁移到 Vue 3 的常见问题5.1 生命周期和全局 API 的变化Vue 3 里很多 API 挪了位置。Vue.nextTick变成了import { nextTick } from vueVue.set直接没有了——因为 Proxy 天然支持新增属性的响应式。生命周期钩子从beforeDestroy改成了beforeUnmountdestroyed改成unmounted如果你从 Vue 2 项目直接拿代码过来第一件事就是全局替换这两个名字。组合式 API 里还有对应的onBeforeUnmount清理定时器、取消事件监听都要在里面对了。另一个容易漏的是this在setup里不可用——Vue 2 里习惯写this.xxx的老手到 Vue 3 得先把this的思维停下来要么用顶层变量要么用getCurrentInstance()。5.2 事件总线的时代结束了Vue 2 里常用$on、$off搭一个事件总线跨组件通信非常方便。Vue 3 把这两个实例方法整个移除了官方态度也很明确跨组件通信请优先考虑 Props/Events、状态管理或组合式函数的复用。我在迁移一个老项目时被这笔账实打实坑过页面里十几个兄弟组件都靠一个 bus 传消息升级到 Vue 3 全部失效。后来我换成了外部mitt这个微型库或者直接把共享逻辑提取成一个返回方法的组合式函数用ref保存状态。这里要特别提醒不要试图在新项目里为了省事继续用 bus 模式事件满天飞的代码调试起来会让整个团队崩溃。5.3 v-model 的用法变迁Vue 3 的v-model跟 Vue 2 相比变化很大。组件上的v-model默认为modelValue属性和update:modelValue事件而不是 Vue 2 的value和input。同时 Vue 3 支持在一个组件上写多个v-model比如传v-model:title、v-model:content每个都有自己的更新事件。这个特性做复杂表单组件时特别好用不用再靠一个v-bind加一个$emit来回传。但注意v-model用在表单原生元素上的行为跟 Vue 2 基本一致容易让人忽略组件层的变化。我见过不止一个同事在封装自定义输入组件时沿用 Vue 2 的props: [value]结果双向绑定怎么都不生效。5.4 ref 与 reactive 的高频坑最后说几个每天都会撞上的细节ref在script里必须.value在模板里自动解包。有个容易误伤的场景在watch里监听ref对象有人直接写watch(myRef, ...)而不是watch(() myRef.value, ...)——结果回调经常不触发。reactive对象被解构后普通变量就失去响应性了。想要保持响应用toRefs或toRef来转换。props是响应式但最好别直接改。把 props 转成本地响应式状态时直接用ref(props.xxx)只会拿到初始值要响应后续更新用computed或watch配合赋值。这些细节不是看一遍文档就能记住的我自己也是踩了两次坑才长记性。建议你在新项目里第一次遇到不生效的绑定先停下来想想我现在操作的是原始对象还是响应式代理我是在读值还是在写值想清楚这两条Vue 3 的大多数响应式问题就解决了一半。我在实际项目里带过不同基础的同事从后端转过来的用 Vue 3 写业务页面基本两周就能独立干活从 Vue 2 过来的老开发反而需要花时间纠正“this 思维”。技术演进就是这样每个阶段的框架都在解决上一个阶段的痛点同时也会逼着开发者升级自己的抽象能力。至此Vue 3 到底要不要学、值不值得学答案其实很明确了它不只是 Vue 2 的小修小补而是前端框架演进到“编译优化组合逻辑”这一代的一个很有代表性的答案。