1. 石器时代没有框架的日子是怎么熬过来的1.1 新手可能会好奇前端框架到底是什么我经常被一些刚入行的朋友问一个问题前端框架这东西到底是干嘛的能不能不学这个问题放在今天问就好像在问手机能不能不用操作系统。但真要回答清楚你得先理解框架出现之前的前端世界长什么样。我入行那会儿正好赶上石器时代的尾巴所以对这段历史记忆特别深。那时候写网页最常见的做法是HTML写结构CSS写样式JavaScript负责操作DOM。听起来挺合理对吧问题出在操作DOM这五个字上。你写一个网页用户点了个按钮数据变了你得手动找到对应的DOM节点然后手动改它的内容、样式、属性。数据一变你得想清楚页面上哪些地方要跟着变一个一个去改。这些操作本身不难难的是当页面变得复杂之后你要保证每次数据变化都和界面严格同步。举一个特别简单的例子。一个商品列表页面有搜索框、筛选条件、排序方式、分页、商品卡片。用户每改一个筛选条件列表要重新请求数据并重新渲染页面上的共XXX条结果、当前选中了哪些筛选条件、分页的页码这些都要跟着变。用原生JavaScript写你的代码会变成一大坨先改这个节点再改那个节点别忘了更新那个span。然后你还会遇到一个更头疼的问题不同浏览器对于DOM操作的兼容性还不一样你常常要写两套甚至三套代码。这就是jQuery存在的意义。它用$(#xxx)这种选择器把操作DOM的方式统一了还封装了不少兼容处理。说实话jQuery在那个年代确实解决了很多痛点。但它本质上没有改变手动同步数据和界面这个工作模式只是让这个模式的手感顺滑了一点。1.2 手动状态同步的噩梦值得每个前端人经历一次如果你想真正理解框架的价值我强烈建议你亲手用原生JavaScript写一个稍微像样点的交互页面不用复杂一个Todo List就行。写着写着你就会发现所有逻辑的复杂度都集中在同一个地方当用户做了某个操作你要更新数据然后还要记得去更新界面上所有和这个数据相关的位置。比如勾选了一个任务任务文本要加删除线底部的剩余任务数要减一如果这个任务正好被过滤条件筛掉了它还要从当前列表里消失。你可能要在一个事件处理函数里写上五六行甚至十几行代码来处理这些连锁反应。更可怕的是当多个操作都会影响同一个界面状态的时候你很容易漏掉某一条更新路径。漏掉一次界面上就会出现数据已经变了但页面显示的还是老样子的bug。这种bug在当年有个专门的名字叫状态和界面不同步。排查起来非常痛苦因为你要顺着用户的操作路径把每一个修改DOM的代码都看一遍才能找到漏掉的那行。我在那个年代养成的一个习惯是每个操作函数开头先写注释把本次操作影响哪些界面区域列出来然后对照着注释一行一行写代码。即便如此还是会在一些冷门的操作路径上翻车。所以后来出现框架这个概念时圈子里的人才会如此兴奋——因为框架本质上是在解决一个当时已经普遍存在、但一直靠人的细心来硬扛的问题数据和界面之间的同步能不能交给工具去保证2. 三大框架的诞生同一批痛点的三种解法2.1 Angular率先登场重型一体化方案2009年前后Google内部孵化的AngularJS横空出世。它提出了一个在今天看来稀松平常、在当时却非常震撼的理念把数据和界面绑定起来你再也不用手动更新DOM了。你只需要维护一份JavaScript里的数据对象然后通过模板语法声明这个数据和页面上这一块有关联剩下的更新操作全部由框架代劳。这个理念叫作数据驱动视图。听起来很美好但AngularJS在实际使用中暴露出的问题也不少它的概念很多指令控制器服务依赖注入每一样都有一堆自己的规则性能上也有先天不足数据一变它就要跑一轮脏检查页面复杂了之后明显感觉卡顿。加上AngularJS后来的版本迭代搞了一次近乎推倒重来的升级很多老项目被卡在升级路上慢慢就失去了民心。不过AngularJS在历史上的地位还是不容忽视的。它最大的贡献不是让所有人都去用它而是向整个行业证明了数据和界面自动同步这条路是可行的让大家看到了前端开发的另一种可能。可以说后来React和Vue能火一定程度上都要感谢AngularJS在前面趟了这条最艰难的路。2.2 React带来函数式思维UI就是数据的映射Facebook在2013年开源的React走了一条和AngularJS完全不同的技术路线。AngularJS那一派是你告诉框架数据和界面的关联关系它帮你维护这一切。React则更像是在说我给你一个函数输入是数据输出是界面。每次数据变了你就把这个函数重新执行一遍得到新的界面然后我来想办法把新界面同步到页面上。为了让每次数据变了都重新执行整个渲染函数这个操作在性能上可行React引入了虚拟DOM的概念。说白了就是先在内存里用JavaScript对象模拟一棵DOM树数据变了就重新生成一棵新的虚拟树然后把新旧两棵树做一次对比算出哪些地方真正变了最后只把这些差异提交到真实DOM上。这招很聪明相当于把计算哪些地方要改这件事从人脑里解放出来交给代码自动去比较。React对前端行业最大的影响是它把一种函数式的思维带进了主流视野界面是数据的纯函数数据变界面就变简单直接。这种思维直到今天都深刻地影响着前端开发甚至影响了后面很多非React系框架的设计。2.3 Vue的中间道路渐进式框架到底渐进在哪在AngularJS和React打得火热的时候2014年左右一个叫尤雨溪的开发者发布了Vue.js。Vue这个名字是法语里视图的意思和英文的view读音差不多。它的核心思想用一个词就能概括渐进式。什么叫渐进式意思是你不需要一开始就全盘接受一套庞大的框架体系。如果你只是想在现有的一个老页面上做一些增强那你可以在页面里引入一个script标签直接用Vue写一块小功能其他部分该用jQuery还用jQuery。但如果你要做一个完整的单页应用Vue也能升级成一套包含路由、状态管理、构建工具的完整方案。这种丰俭由人的设计让Vue在一众框架里显得特别友好。Vue的作者本身是从React和AngularJS这两个社区里吸收了大量养分才设计出Vue的。它的核心思路是结合AngularJS的声明式模板和React的组件化思路再自己发明了一套基于依赖追踪的响应式系统想要做到既好用又高效还不需要太高的学习门槛。事实也证明这条路确实走通了。Vue在中国市场尤其流行很多公司和团队选择它作为主力框架很大程度上就是因为它的文档对中文用户友好、上手曲线平缓、团队培训成本低。3. 数据驱动视图的演进主线从模板引擎到响应式系统3.1 第一阶段的探索模板引擎还是换皮在真正讲数据驱动之前前端界其实已经有过一波模板引擎的尝试。最早的做法是这样的你写一个HTML模板里面留一些占位符比如{{ name }}然后你用JavaScript把数据塞进去拼出一段完整的HTML字符串再用innerHTML扔到页面里。这种做法看起来已经有点数据和界面分离的意思了但它有一个根本问题**每次数据变化你都要重新拼接整个HTML字符串然后把整个区块的DOM全部替换掉。**这意味着用户输入框里的内容会被重置滚动位置会丢失图片会重新加载而且频繁操作大段DOM对性能压力很大。说白了模板引擎只是把手动改某个节点变成了整块重刷治标不治本。那个阶段还有一个常见的衍生问题容易产生XSS安全漏洞。因为你是把数据直接拼进HTML字符串如果数据里带了恶意脚本又没做转义处理那用户一打开页面就出事了。后来框架普遍改成用API创建DOM节点、以节点方式插入才从机制上大大缓解了这个风险。3.2 虚拟DOM的价值拿计算换操作虚拟DOM之所以后来成为主流方案不是因为它的计算效率真的比精细操作真实DOM快多少而是它在开发体验、代码可维护性和性能之间找到了一个很好的平衡。你想啊如果让你手写精确更新哪一块DOM的代码那性能确实可以做到极致——因为你可以针对每一个场景写最针对性的操作。但现实是页面复杂到一定程度精确更新哪一块这件事本身就已经超出人脑能轻松管理范围了。虚拟DOM的思路是我不要求程序员自己分析哪些地方变了你来写整个视图应该长什么样我来负责做差异比较、找出变化、只提交变化部分。在这个过程中程序员的生产效率大大提升付出的额外代价是一些运行时的计算成本。这笔账在绝大多数业务场景下是划算的。Vue 2和Vue 3也都用了虚拟DOM但同时保留了模板编译的选项这和React是有区别的。React是完全在运行时通过JSX生成虚拟DOM而Vue会先把模板编译成一个渲染函数在编译阶段就能做一些优化标记这样运行时就能跳过一些不必要的比较逻辑。这一块的性能调优也是Vue 2到Vue 3的重要进步方向。3.3 响应式系统Vue路线的核心机密AngularJS用脏检查来实现数据和界面的同步React用手动触发setState然后整棵树重新渲染来实现同步而Vue选择的方案叫响应式系统。它的底层逻辑是你把一个普通JavaScript对象传给VueVue会把它变成一个可观察对象也就是说当这个对象上的某个属性被读取时Vue能知道有人在读它当这个属性被修改时Vue也能知道它变了。然后Vue会在这个属性的依赖列表里记录所有用到了这个属性的视图变量一变Vue精准地只更新这些密切相关的部分。这就是Vue 2时期依赖收集和派发更新的设计。它的优点是精准、细粒度数据变哪里就更新哪里缺点是当你的数据层次很深、结构很大的时候收集依赖和维护整个监听系统的成本会变得很高。而且Vue 2的响应式是基于Object.defineProperty这个API它有一些天然的短板无法监听新增属性、删除属性、数组索引变化等操作。为了解决这些短板开发者在Vue 2时代常常要写不少Workaround变通办法比如Vue.set、Vue.delete或者用this.$set来手动触发更新总之体验有些别扭。这个短板要到Vue 3全面切换到Proxy之后才彻底解决。4. Vue 2到Vue 3不只是快了一点4.1 Proxy重写响应式从补丁式到全能力式Vue 3改用ES6的Proxy来重写响应式系统是这一版最重要的底层变化之一。Proxy和Object.defineProperty的区别在于前者能拦截一个对象上的所有操作包括新增属性、删除属性、判断属性是否存在、读取属性描述、监听数组的变化、甚至拦截in操作符和for...in遍历。后者只能拦截到读取某个已有属性的值和修改某个已有属性的值这两种操作。这个变化带来的直接体验提升是实实在在的在Vue 2里你往data对象上新增一个属性页面不会自动更新必须调用this.$set手动补一次通知。在Vue 3里你直接obj.newProp 1页面就跟着变了一切都显得特别自然再也不需要那些补丁式的API了。数组操作的体验提升更明显在Vue 2里直接arr[0] xxx是不触发更新的很多人被这个坑害过无数次到Vue 3也彻底解决了。很多人在学习Vue 3时不太关注这个底层变化觉得反正用起来差不多。但我的建议是一定要花时间理解Proxy的拦截机制。因为这个机制直接决定了你在Vue 3里写响应式代码时的边界在哪里——比如你在reactive对象上解构属性会丢失响应式因为解构出来的是普通变量和你解构一个普通对象没有任何区别。这些细节如果你不懂底层原理出了问题根本无从下手排查。4.2 Composition API到底解决了什么问题Vue 3推出的组合式API刚出来时争议挺大因为Vue 2时代大家已经习惯了Options API也就是把一个组件写成data、computed、methods、watch这样的选项块。这种写法在组件简单时很好理解但当组件逻辑复杂起来你会发现同一个业务流程的代码被拆散到了不同选项里请求数据写在created钩子里处理逻辑写在methods里计算属性写在computed里监听逻辑写在watch里。你想看懂这个组件里和某个功能有关的全部逻辑就需要上上下下翻遍好几个选项块。组合式API的出发点简单来说就是按逻辑关注点组织代码而不是按代码类型组织代码。你可以把一个功能需要的所有状态、方法、副作用都写在一起甚至可以提取成一个独立的函数useXxx()从一个组件里抽取出来给多个组件复用。这种能力大大提升了中大型组件的可维护性也顺带让Vue 3和TypeScript的配合顺畅了很多——组合式API里的函数返回值类型推断起来比Options API里this上的类型推断容易得多。但我想说一句公道话组合式API并不是要彻底取代Options API它更像是在复杂场景下提供一条更合适的路径。你完全可以一个项目里两种写法混用简单的组件继续用Options API复杂的组件用Composition API。框架文档也是这么推荐的。具体到个人选择就看你团队的技术统一性和代码审查的便利性了。4.3 编译时优化虚拟DOM的补丁策略升级很多人看Vue 3的性能提升只看到了响应式系统的变化其实编译阶段的优化同样关键。Vue 2的虚拟DOM对比是全量对比渲染函数执行生成一棵完整的虚拟树之后要和旧树逐节点比较即便某些节点完全没有变化比较的逻辑也要跑一遍。模板越复杂比较的开销就越大。Vue 3在编译阶段引入了静态树提升、静态属性提升、动态节点标记这些优化手段。简单解释一下编译模板时Vue 3会自动识别出哪些节点是永远不变的静态节点并把它们提升到渲染函数外只生成一次对于动态节点它会用特殊的标记记录下这个节点上有哪些动态属性这样在Diff阶段框架只需要比较被标记的动态部分跳过所有静态内容的对比。效果就是页面静态内容越多Vue 3的渲染性能相对Vue 2的提升就越明显。再加上PatchFlags和Block Tree的机制Vue 3可以把哪个动态节点在模板里的哪个位置用扁平的结构记录下来对比时直接沿着这个结构走不再需要一层一层递归遍历整棵树。把这些优化叠加在一起才是Vue 3在渲染性能上明显拉开Vue 2差距的完整原因。所以别再只记住Vue 3用了Proxy所以更快这种简单话了响应式升级和编译优化是两条腿一起走的。5. 为什么值得学Vue 3就业、生态和团队体验的现实考量5.1 就业市场的真实情况学Vue 3不是选择而是默认回到标题的问题Vue 3为什么值得学从就业角度讲是最直接的答案。我身边陆续有好几个在技术团队做前端负责人的朋友这两年聊起招聘基本都已经统一了口径新项目一律用Vue 3简历上写熟悉Vue 2但不了解Vue 3的候选人至少要被打折看待。而且很多公司虽然老项目还是Vue 2但岗位JD早早就写上了精通Vue 3。这个趋势在社区里也看得到。Vue 2的代维时间到2023年底就已经正式结束了虽然它出安全补丁的服务延了一段但版本整体已经进入维护尾声。各主流UI组件库、工具库都全面转向Vue 3版本新开源项目默认支持的就是Vue 3。你现在新开一个项目如果还用Vue 2不仅大量新工具没法用连提Issue都可能被社区维护者劝退升到3再说。这个现实已经容不得你纠结选不选它就是前端求职和在岗项目开发的事实标准。5.2 生态建设从Element Plus到Nuxt 3都在3时代生态方面Vue 3发布已经好几年了周边工具的成熟度早就过了第一个版本发布时的粗糙期。UI组件库层面Element Plus、Ant Design Vue、Naive UI都已经适配Vue 3而且积累了大量的迭代反馈坑基本都被填平了。服务端渲染框架Nuxt 3也是基于Vue 3的重写版本它带来了更强悍的模块化能力和自动导入机制写全栈应用的体验比Nuxt 2好了一大截。移动端的uni-app也在大力推荐Vue 3语法不少团队的跨端项目已经全面迁到uni-app的Vue 3版本上。如果你要在项目里用到状态管理Vue 3时代的Pinia比Vue 2时代的Vuex好用了不止一个档次。它抛弃了mutations的繁琐概念类型支持更完整还天然支持组合式API的写法。我个人的体感是用Pinia写状态管理像写普通模块一样心智负担比Vuex时代低了很多。这些都算是生态成熟带来的实际收益。5.3 TypeScript支持和团队协作进阶需求的硬门槛除了上面这些Vue 3值得学的另一个理由是TypeScript。Vue 3的源码本身就是用TypeScript写的框架层面的类型定义完整度比Vue 2高了好几个量级。这对于工程化团队来说非常重要组件props的类型推导、事件回传的参数类型、store的状态类型都能在编译期就被检查出来很多低级错误在开发阶段就能被拦截而不是上线后被用户在浏览器里踩出来。团队协作上Composition API配合TypeScript之后代码的可读性和可维护性也会上一个台阶。新成员接手一个用Options API写的复杂组件常常要花很久梳理各种选项块之间的隐式关联而面对一个按功能拆成多个useXxx组合式函数的组件他能立刻顺着函数名理解这个组件大概做了哪几件事再逐个函数深入去看细节。这种感觉用过几次之后基本就回不去了。6. 学习建议从演进的角度学框架而不是背API6.1 先建立问题意识再学工具知识才能扎根最后说一点学习路线的个人体会。每次看到有人拿着一份Vue 3 API速查表就开背我都觉得特别可惜。API是学不完的今天记了ref和reactive用法明天又会冒出toRef、shallowRef、triggerRef后天还有customRef、computed的各种配置项。你如果只记用法不建立框架在解决什么问题的意识那API表里的每一个新名词对你来说都是等价的死记硬背。更好的方式是先回到我在第一章里描述的那个石器时代自己亲手用原生JavaScript写一个稍微复杂的交互页面体验到状态同步的痛苦然后想象如果有一个工具能自动帮我同步数据和界面那这个工具需要哪些能力。当你带着这些问题去看Vue 3的文档你会很自然地理解响应式系统是为了解决什么、组件化是为了解决什么、路由和状态管理又是为了解决什么。这个由问题驱动的学习路径比由API驱动的路径扎实太多。6.2 一条实践路线从Todo List到综合项目具体的练习路径我推荐这样走第一步用Vue 3写一个Todo List不带任何周边库只用ref和表达式更新把Vue的响应式基础摸一遍。第二步自己试试把Todo List改成组合式API的写法把一个功能相关的状态和操作提取到一个useTodos函数里体会Composition API的代码组织方式。第三步给它加上Pinia状态管理再配上简单的Vue Router切换页面这就开始接触工程化的常见姿势了。做这个练习时我特别建议你多试几个非标准操作比如在v-for循环里改动数组某个元素比如给响应式对象动态添加一个新属性比如把一个响应式对象整体替换成另一个对象。这些场景在面试里常被问到也是实际开发中最容易踩坑的边界行为。你亲手试过、观察过行为、再回去查文档搞清楚原理这块知识才算真正长在你身上了。6.3 框架还在演进但底层逻辑才是定海神针前端框架这几年的发展速度确实快但如果你站在时间线上回头看会发现核心脉络一直没变从手动操作DOM到声明式绑定到组件化组织再到更精细的性能优化和更好的TypeScript支持整条线都是在降低心智负担和提升可维护性之间寻找更好的平衡点。Vue 3正是这条演进路径上的一个重要节点。所以与其焦虑框架会不会又被新的替代不如花时间练好那些不变量JavaScript语言基础、DOM和浏览器工作原理、数据驱动视图的思维方式、组件抽象的能力。这些底层能力在任何框架更迭中都是通用的而具体到Vue 3它今天的模型设计和工程生态已经足够让它成为这个时代最值得投入精力的前端框架之一。我个人的看法是与其纠结学Vue 2还是学Vue 3不如直接把Vue 3作为起点它的设计语言里已经包含了对过去所有教训的正视——这本身就是最好的学习材料。