尤雨溪的Vue与Vite取舍：前端学习路线与AI时代出路

把"尤雨溪"三个字丢进任何一个前端群，五分钟之内就能吵起来。有人把他当偶像，说他是"前端男神"，一个人撑起了一个生态；也有人不服气，觉得他不过是踩中了时代窗口，换个人也能成。我在一线写了十来年前端，做过小公司的全栈、也在大厂做过中后台和 C 端页面，参与过框架选型、组件库治理、微前端拆分，也当过面试官。我的结论可能有点反直觉：尤雨溪最厉害的地方，其实不是"代码写得好"——前端圈代码写得好的人多得是，他真正稀缺的能力是持续十几年做"取舍"，并且把取舍的结果讲清楚、卖出去。

这篇文章我想做的不是复述一遍百科式的生平，那玩意搜一下就有。我想拆的是他身上可被复现的那部分：一个设计背景出身的人，怎么一步步变成 Vue 和 Vite 的作者？他在关键节点上做的那些技术决策，背后是什么逻辑？这些逻辑对一个正在准备前端面试、正在规划前端学习路线、或者正在焦虑"AI 时代前端还有没有出路"的普通开发者，到底能抄走什么？不管你是刚学完 HTML、CSS 就被 v-if 和 v-for 绕晕的新手，还是已经能独立带项目、开始纠结"要不要转 Agent 开发"的老手，下面这些内容都值得你看完。

1. 一个设计系学生，是怎么变成框架作者的

聊尤雨溪的成长路径，最有意思的不是"他学了什么"，而是"他缺了什么"。他不是计算机科班出身，大学读的是帕森斯设计学院，这个起点决定了他后来看框架的视角和大多数纯工程背景的作者完全不同。这个差异，在他后面做 Vue 的每一个决策里都能看到影子。

1.1 帕森斯那几年：他练的是"上手手感"，不是算法竞赛

设计训练给一个程序员的加成，外人往往低估。设计学院教的核心东西是：用户第一次接触某个东西的前三秒会发生什么，他会不会困惑，会不会放弃。你天天被逼着改一版又一版的作品集、被导师问"你为什么这么排版"，慢慢就会对"门槛"这件事极度敏感。

把这种敏感度搬到框架设计上，就是另一套评判标准。多数框架作者关心的是"这个抽象是否严密、是否可组合、是否学术上漂亮"，而尤雨溪更关心"一个只会写 HTML 的人，五分钟能不能跑起来一个能用的页面"。这两个标准并不冲突，但优先级不同，优先级不同的结果就是 API 长相完全不同。

我打个生活化的比方：有的框架像一台手动挡性能车，参数拉满、操控上限极高，但你得先学会踩离合；有的框架像一台调好的电瓶车，拧一下就走了。哪种更好？看你要去哪。但如果你是做企业后台、做中小型产品、做需要快速交付的业务，电瓶车的价值被严重低估了。这个判断，尤雨溪当年是押对了的。

1.2 Google Creative Lab 那段：把技术当表达工具的人

公开履历里，他待过 Google 的 Creative Lab，也做过创意实验类的项目；后来又在 Meteor 做过核心开发。这两段经历的性质差别很大，但对他的塑造是同一件事：技术不是目的，表达才是目的。

Creative Lab 那类项目的特点是，技术选型完全服务于"这个东西看起来酷不酷、体验顺不顺"，而不是"架构是否可维护十年"。在这种环境里待久了，你会形成一种本能：先想用户看到什么，再想代码怎么写。这个顺序，恰恰是很多纯工程背景开发者倒过来的——先想架构怎么优雅，再去想用户要什么。

后来 Vue 的很多细节都能看出这种痕迹。比如单文件组件（SFC）把 template、script、style 放进一个文件里，从工程学的角度没什么必要，甚至有人批评它"把三种语言塞一起不干净"；但从"一个人维护一个页面"的视角看，它就是最省心的组织方式。再比如 Vue 官方文档的质量，在开源框架里常年属于第一梯队，示例可以整段复制粘贴直接跑，这背后还是设计思维——文档就是产品的一部分。

提示：这一点对普通开发者更有用的是反过来用。如果你现在写业务代码时，先想的是"我这个 Hook 抽得漂不漂亮"而不是"用户点完之后会发生什么"，那你可能已经跑偏了。抽象是手段，交付才是目的。

1.3 Vue 的起点：一个"抽出来"的副业项目，而不是一个"要做框架"的宏愿

Vue 的诞生故事很朴素。他当时在用 Angular 做原型，data-binding 那套东西用起来确实爽，但 Angular 体量太重，而且它的野心太大——路由、依赖注入、模块体系、测试方案全都要管。你只想给一个页面加一点数据驱动的交互，却被塞进一整套世界观。

于是他做了一个很多老手都会做但很少坚持下来的动作：把"我真正想要的那一小块"抽出来。那一小块就是响应式数据 + 模板渲染。2014 年 2 月首次公开发布的时候，这个东西的定位非常克制——不是什么大而全的解决方案，就是"让视图层写起来舒服一点"。

这段经历的价值在于它示范了一个可复制的判断方式：当你被某个工具烦到的时候，先别急着换工具，试着问自己"我到底要它的哪一部分能力"。如果你能把那部分单独拿走、用最小成本用上，你就有可能做出一个真正有用的东西。Vue 早期在海外社区也被吐槽过"又一个轮子"，但它在两类场景里迅速扎下根：一类是只需要局部增强的老项目，另一类是当时的 Laravel 社区这类"后端开发者顺手要写前端"的群体。这两类人有个共同点：他们不想要一套需要专门学习的架构，他们想要一个能立刻干活的工具。

2. "不跟 Angular、React 硬刚"：Vue 的技术取舍拆给你看

一个框架能活十年，靠的绝不是"功能比对手多"。Vue 在每一个关键岔路口都做了明确的取舍，有的地方甚至主动放弃了"技术上的优雅"。这些取舍背后的逻辑，比框架的 API 本身更值得学。

2.1 模板语法 vs JSX：他为什么死守 HTML 写法

这是争议最大的一点。"既然 JavaScript 已经能做一切，为什么要发明一套模板语法？"这个问题我被问过无数次。答案其实分两层。

第一层是人群覆盖。地球上会写 HTML 的人远多于会熟练写 JavaScript 抽象的人。模板是 HTML 的超集，它的学习曲线几乎是平的，这直接决定了框架能被多少后端、多少刚入门的人用起来。

第二层才是技术层面的关键：模板是可被静态分析的。编译器在构建时就能知道哪些节点是静态的、哪些绑定了数据、哪些会随条件变化。所以 Vue 3 编译出来会带上PatchFlag、静态提升（hoistStatic）、以及v-if分支的缓存，运行时 diff 时要比较的节点数量被大幅削减。JSX 因为本质是 JavaScript 表达式，自由度更高，但编译期能确定的信息也少得多，很多优化只能靠运行时扛或者靠额外的编译手段去猜。

我给你看一段直观的对比，同一个渲染逻辑，编译产物差别很大：

// 模板写法：编译器能一眼看出 msg 是唯一的动态部分 // <div class="static"><span>{{ msg }}</span></div> // 编译后大致等价于： import { createElementVNode as _createElementVNode, toDisplayString as _toDisplayString, openBlock as _openBlock, createElementBlock as _createElementBlock } from "vue" function render(_ctx) { return (_openBlock(), _createElementBlock("div", { class: "static" }, [ _createElementVNode("span", null, _toDisplayString(_ctx.msg), 1 /* TEXT */) ])) }

注意那个1 /* TEXT */的标记，它告诉运行时"这个 span 里只有文本是动态的"。静态的 div 和 class 属性在更新时根本不会被碰。这就是模板换来的东西——不是语法层面的，而是性能层面的。

我的实际感受是：JSX 在"高度动态、需要程序化生成结构"的场景里更顺手，比如渲染一张列数不定的表头、按配置拼装组件树；模板在"结构相对稳定、以数据绑定为主"的业务页面里写起来更快、更不容易写出性能坑。很多人吵这个问题，是因为他们默认只能二选一，而 Vue 其实两套都给了。

2.2 "渐进式"这三个字，救了多少老项目

渐进式（Progressive）是 Vue 最成功的定位，没有之一。它的具体含义是：你可以只用它的一小部分。一行<script src="...vue.js"></script>，然后在老页面的某个 div 上挂一个实例，这个页面就获得了数据驱动能力。剩下的部分——路由、状态管理、构建工具、服务端渲染——你想用哪个再拿哪个。

这个设计对企业项目的意义巨大。我做过好几个"祖传 jQuery 页面"的改造，最省事的方案从来不是重写，而是先在新需求模块上挂 Vue，稳定跑一个版本之后再往回蚕食。这种"局部上船"的策略，迁移风险低到业务方都没什么感觉。这也是为什么大量中后台系统、内部工具、嵌入式管理页面最后都落在 Vue 上——不是因为它技术最先进，而是因为它的进入成本最低。

代价当然有。渐进式意味着整个生态是拼装的，路由用 vue-router、状态用 Pinia、构建用 Vite，每个都得单独学、单独配版本。React 那边虽然也是拼装，但社区默认组合相对集中。所以 Vue 项目的技术栈一致性，更多时候靠团队规范而不是框架本身约束。

2.3 响应式的三次迭代：从 defineProperty 到 Proxy，到底改了什么

面试里被问烂的一道题："Vue 2 和 Vue 3 的响应式原理有什么区别？"大部分人能背出"defineProperty 换成了 Proxy"，但追问一句"为什么换"就卡住了。我把这个问题拆开讲。

Vue 2 用Object.defineProperty递归给对象每个属性装 getter/setter，数组则通过改写push、splice等七个方法来实现拦截。这套方案有三个硬伤：

• 新增属性、删除属性无法被追踪，必须用Vue.set/Vue.delete，这是个长期被吐槽的心智负担。
• 数组下标赋值、length修改无法追踪。
• 初始化时要把整个数据对象递归遍历一遍，对象越大启动越慢，不管这个属性后面用不用。

Vue 3 换成Proxy之后，拦截的是"对对象的操作"而不是"对某个属性的读写"，前面三个问题一次性消失：新增属性天然可追踪，Map、Set这类集合也能支持，而且可以实现懒代理——只有真正被访问到的嵌套对象才递归包一层。性能提升不是靠某个黑魔法，而是靠"少做无用功"。

原理说清楚之后，我建议你亲手写一个三十行的迷你响应式，比看十篇分析文章都管用：

// 极简 reactive + effect，够你理解依赖收集和派发更新 let activeEffect = null function effect(fn) { activeEffect = fn fn() // 首次执行，触发 get，完成依赖收集 activeEffect = null } function reactive(target) { const deps = new Map() // key -> Set<effect> return new Proxy(target, { get(obj, key) { if (!activeEffect) return Reflect.get(obj, key) if (!deps.has(key)) deps.set(key, new Set()) deps.get(key).add(activeEffect) return Reflect.get(obj, key) }, set(obj, key, value) { const result = Reflect.set(obj, key, value) const set = deps.get(key) if (set) set.forEach(fn => fn()) // 派发更新 return result } }) } const state = reactive({ count: 0 }) effect(() => console.log('count is', state.count)) // 收集依赖 state.count++ // 触发重跑，打印 count is 1

跑一遍这段代码，你对"依赖收集""副作用""派发更新"这几个词的理解会立刻落地。之后再去理解 Vue 3 里track/trigger、ref和reactive的区别、computed的惰性求值，都是在这套骨架上加东西。至于后续版本里对响应式做的链表化依赖存储、版本计数这类优化，公开分享里讲得很清楚，核心思路一直是"减少不必要的遍历和触发"。

顺便说一个方向上容易被忽略的事：Vapor Mode 这类探索，本质是想把虚拟 DOM 这一层也省掉，走编译期直接生成精确操作 DOM 的代码。这不代表虚拟 DOM 错了，而是场景变了——在大量静态结构、少量动态绑定的业务页面里，虚拟 DOM 的运行时开销确实是可以省的。理解"为什么现在又不需要它了"，比记住"Vue 用了虚拟 DOM"更有价值。

3. 开源项目活下去，靠的从来不是热情

写开源项目的人多如牛毛，能把一个框架维护十年、还持续给出大版本演进的，屈指可数。中间隔着的不是技术水平，是组织、资金和判断力。这一段讲的是尤雨溪最不容易被复制的那部分能力。

3.1 从 Meteor 辞职去做全职开源：钱从哪来

2016 年前后，他从 Meteor 离职，全职投入到 Vue 上。这件事在当时是非常冒险的——没有公司背书，没有大厂实验室养着，收入来源主要靠社区赞助（Patreon 那一类）。这是一个很多人不敢想的决定，因为开源维护的现实是这样的：

• 写核心代码只占很小一部分时间。
• 大量时间花在处理 issue、回答提问、写文档、发版本、协调贡献者。
• 用户越多，抱怨越多，而且大部分抱怨带着"你必须马上修"的语气。

我见过太多人做了个两千 star 的库，半年后就再也不更新了，原因几乎都一样：投入产出比崩了。尤雨溪能撑下来，除了框架本身被用得多，另一个关键动作是把社区组织化——建立核心团队、引入 RFC 流程、让不同的人负责不同模块、把发布节奏固定下来。Vue 的 RFC 仓库是个很好的范例：一个重要的 API 变更，先写提案、公开讨论、收集反馈，再决定要不要合。这套流程让社区感觉"我参与了框架的设计"，也把决策压力从一个人身上分摊了出去。

注意：如果你自己也在维护开源项目或者公司内部的公共库，尽早把"我一个人的判断"变成"一份公开的规则"。前者你一旦请假整个项目就停摆，后者才能活过你的精力周期。

3.2 Vue 3 重写与 Vite 的诞生：2020 年那两次豪赌

Vue 3 是免费的午餐的反面。重写意味着生态要跟着重排：TypeScript 全面重写、Composition API 引入新的代码组织方式、虚拟 DOM 和响应式全换、周边库（状态管理、UI 库、构建插件）都要跟版本。短期看，这是纯粹的"给用户添麻烦"——无数团队卡在"Vue 2 挺好用的为什么要升"上。

但如果不重写呢？defineProperty的天花板、类型系统的缺失、大型项目下的性能瓶颈、以及当时构建工具的启动速度问题，都会积累到五年后集中爆炸。我自己的判断是：这一步必须走，只是时间点选得不算完美——升级路径的平滑程度确实被低估了，很多团队因此长期停在 Vue 2，直到 Vue 2 官方支持周期结束才被迫迁移，那个迁移过程比当年主动升要痛苦得多。

紧接着是 Vite。这个项目的切入点特别精准：那几年大家最大的日常痛苦就是"改一行代码等十几秒"。Vite 的解法是开发时直接利用浏览器原生的 ESM 能力，只对用到的模块按需编译，把依赖用 esbuild 预构建一次；生产构建再交给 Rollup 打包。结果是冷启动从几十秒掉到接近瞬时，热更新几乎感觉不到延迟。

这里有个特别值得学的思维习惯：遇到长期存在的普遍痛点时，先问"是不是我们一直以来的做法本身就有前提假设可以推翻"。以前之所以要"先打包再开发"，是因为浏览器不支持模块；而这个前提早就变了，只是大家的工具链还在沿用旧习惯。这类机会比"把某个环节优化 20%"值钱得多。

3.3 "Vue 只适合小项目"这句话，是怎么被造出来的

这个说法流传很广，我听过的最离谱的版本是"Vue 做不了大型系统"。它有一个现实来源：上手太容易 + 门槛太低 = 大量没受过工程训练的开发者涌入，产出了一批没有测试、没有分层、状态乱飞的项目。项目烂了，锅被扣到框架头上。

我的实际观察是反过来的。我参与过的一个后台系统，几十个业务模块、上百个路由、多团队并行开发，用的是 Vue 3 + TypeScript + Pinia + 内部组件库，配合工作流引擎的流程编排，前端复杂度不低，但只要状态边界划清楚、组件分层定死、请求层统一封装，可维护性一点不比其他栈差。大型项目烂不烂，取决于团队有没有工程纪律，跟框架姓什么关系不大。

真正该反思的是：上手快这件事会掩盖团队基本功的缺失。React 用起来麻烦一点，反而逼着新人先学抽象和分层；Vue 太顺，容易让人以为"能跑起来就是对的"。这也是我给带团队的人的一点建议——如果你们用 Vue，一定要在项目初期把工程规范补上，因为它不会替你挡住这些事。

4. 把他的路径翻译成你自己的前端学习路线

聊完故事和决策，回到最实际的问题：一个普通前端，能从这个人身上抄走什么？我把答案整理成三段可执行的东西，分别对应能力模型、面试准备和职业方向。

4.1 三个阶段的能力模型：从"会写页面"到"能做取舍"

我把前端的能力分成三层，你可以对照看看自己在哪。

前两层靠练，第三层靠经历。尤雨溪的第三层能力，是在"用 Angular 用得难受"、"要不要重写 Vue 3"、"要不要做 Vite"这些真实决策里练出来的。普通开发者想在第三层上成长，最快的路径不是看更多文章，而是去承担一个有真实代价的决定——比如选型，选错了要背锅的那种。

4.2 面试官问"响应式原理"，其实在考什么

现在的前端面试，从初中级到高级，考点分布其实很稳定。我把常见的几类和它们真正想考的东西列一下：

• 响应式 / 渲染原理：不是考你能背多少，而是考你有没有动手验证过。你写过上面那段三十行的 Proxy 代码，回答时的颗粒度完全不一样。
• 编译时优化：v-if和v-show的选择、key的作用、静态提升，考的是你知不知道"框架在替你做什么"，因为不知道就没法做性能判断。
• 工程化：构建配置、环境变量、分包策略、按需加载、体积治理。这块是区分中级和高级的分水岭，很多候选人能写业务但不能解释自己的构建产物为什么是两个 G。
• 状态管理与边界：什么时候上全局状态、什么时候用 URL 参数、什么时候用请求缓存。这题考的是经验，不是知识。
• 场景题：大文件上传、长列表卡顿、白屏排查、跨端适配。面试官想听的是你的排查链路，不是标准答案。

一个实用建议：把你做过的每个项目，按"问题—方案—代价—结果"四段式整理成二十来个卡片。面试时遇到类似问题直接调卡片，比临场组织语言可靠得多。至于机试和在线笔试，最大的坑是"题目读太快"和"边界条件不考虑"，我见过太多人在字符串处理题上因为没处理空输入直接挂掉——笔试里的分，是真金白银，别浪费在读题上。

4.3 AI 时代前端的出路：岗位没消失，职责在挪

这两年"前端是不是要没了"的声音特别大。我的判断是：纯粹切图、纯粹搬组件的岗位确实在萎缩，但前端在 AI 应用里的位置反而在变重要。原因很直接——所有大模型的能力最终都要通过界面交付给人，而界面可靠性、流式渲染、状态一致性这些事，正是前端的专业领域。

具体往哪些方向挪，我看到几个明确的机会点：

• 流式交互：对话式产品的核心是流式输出（SSE / WebSocket），要处理中断、重试、多路并发、Markdown 实时渲染、代码高亮增量更新。这块的工程复杂度远高于普通表单页面。
• 工具调用的可视化：Agent 会调用各种工具，前端要把调用链路、中间结果、失败重试清楚地呈现出来。这本质是复杂状态机 + 可视化，前端的老本行。
• 状态可靠性：AI 应用特别容易状态错乱，比如用户连点两次发送。仔细想想，这个问题的本质和"重复提交订单"是同一类问题——幂等设计、乐观更新回滚、请求去重。前端在这块的积累可以直接迁移过去。
• 工程侧：模型输出的不确定性让前端必须更严格地做降级、超时、兜底。这些是纯工程能力，AI 帮不了你。

所以"前端转 Agent 开发"这条路，我的建议不是丢掉前端去学训练模型，而是站在前端的壳里往深走一层：把异步、状态、渲染这三件事做到极致，再补一点后端和协议层的知识（消息队列的幂等、服务端推送的机制），你在 AI 产品团队里的不可替代性就出来了。反过来，如果你只会调接口、拼页面，那确实是危险的位置。

5. 我踩过的坑：把"取舍思维"落到真实项目里

道理讲完，落不到项目里都是空的。下面这三个坑是我自己踩过或者亲眼看着团队踩过的，共同点是：方向都没错，错在没做取舍判断。

5.1 组件库：Element Plus 能覆盖 80%，剩下 20% 才是成本所在

用现成组件库起步当然对，尤其是中后台。但真正的成本不在"用不用"，而在"那 20% 定制需求怎么处理"。我见过两种典型翻车方式。

一种是"扛着改"：直接改组件库源码，或者用一堆深层选择器、::v-deep覆盖样式。升级组件库版本时全线崩，没人敢动。另一种是"全自研"：觉得组件库不合口味，从按钮开始造，半年时间造出一套不如人家的东西，业务需求一个没做。

我后来稳定下来的做法是三层结构：

• 基础层直接用组件库，不加任何魔改。
• 中间层做一层薄封装（业务无关，只统一交互约定，比如所有表格的分页参数、所有表单的校验提示位置）。
• 业务层再包一次，处理真正的业务差异。

这样组件库升级只需要改中间层，业务代码基本不动。判断"要不要自研"的标准也很简单：如果这个组件在三个以上业务里长得不一样，就该自研；如果只是样式不一样，那叫主题，不叫自研。

5.2 微前端：不是所有中后台都该上 qiankun

微前端被吹了很久。我在一个项目里真的用了之后，得到的教训很具体。

它解决的问题是真问题：多个团队维护同一个大后台，技术栈不同、发布节奏不同、构建产物互相牵连。但它带来的成本往往被严重低估：跨应用的样式污染、路由状态同步、公共依赖版本冲突（两个子应用各自打包了不同版本的 Vue）、跨应用通信的调试困难、以及最要命的——本地开发环境的搭建复杂度直接翻倍。

我的判断标准是这样的：

如果确定要上，我的经验是：公共依赖一定要走共享（比如通过 externals + 统一 CDN 或 import map），否则包体积会失控；样式一定要隔离（沙箱或者前缀约定二选一，不要指望自动隔离万无一失）；子应用之间的通信只允许通过一层明确的事件总线，禁止互相 import 业务代码。

5.3 那些看着不起眼、出事很致命的前端细节

最后这部分是我攒下来的零碎经验，都是真出过事的。

大文件上传。浏览器主线程一旦被分片计算和哈希占住，页面直接卡死。我的做法是把文件切片、计算哈希这些 CPU 密集操作放进 Web Worker，主线程只负责状态展示和进度更新。再配合分片并发控制（并发数别超过 3）和断点续传，用户体验会好很多。另外必须处理"用户连点两次上传按钮"的情况，前端要做请求去重和幂等标记，这和后端做幂等是一套思路。

图片前端压缩。上传前用 Canvas 或createImageBitmap压缩，能省下大量带宽和后端存储。但要注意两件事：一是方向信息（EXIF 里的旋转标记）在部分手机上会被丢掉，压缩后图歪了；二是压缩要放到 Worker 或者按需串行执行，否则批量选图时会明显掉帧。

大屏自适应。方案不少，核心是先定基准设计尺寸，再选缩放策略（等比例缩放 / rem 换算 / CSS 容器查询）。我的教训是别混用，最怕的是有人用 rem 做整体缩放，又在局部写了固定 px，"自适应"变成了"局部错位"。

数据 Mock。接口没好的时候用 Mock 工具（比如基于 Service Worker 的方案）能让前端独立推进，但一定要定好"Mock 数据契约"，否则接口真上线时字段名对不上，返工成本比不 Mock 还高。

本地开发环境踩的坑。你一定见过"端口被占用""依赖锁冲突"这类报错，本质是多个进程抢同一份资源。在国内网络环境下，装依赖慢也会被误判成配置错误。我的习惯是：所有项目统一用锁定文件 + 固定 Node 版本（.nvmrc或 engines 字段），把环境问题挡在协作之外。

再补一句关于"技术选型要跟着业务阶段走"的体会。早期项目要做的是"快速验证"，选型要的是启动快、上手快；中期进入规模化，选型要的是可维护性和类型安全；后期做多端和性能治理，才需要考虑 SSR、编译优化这些重活。我见过太多项目在早期就抄了后期架构，结果开发速度被拖垮，业务还没验证就先被架构拖死了。尤雨溪把 Vue 做成渐进式，本质上就是这个道理——不同阶段用不同深度，别一步到位。

我自己用 Vue 和 Vite 这么多年，最有价值的一课不是某段源码，而是他反复展现的那种做法：先把问题定义清楚，再选一个能覆盖 80% 场景的方案，剩下的 20% 用约定和文档兜住，然后坦然接受这个方案带来的代价。这套做法放在框架设计上叫渐进式，放在你手上的业务项目里，叫"别过度设计，也别裸奔"。