前端框架选择的思考

前端框架选择的思考

起因：某天整理电脑，扫描了一遍自己的 Project 文件夹，发现 40 多个项目里，Vue2、Vue3、React、Angular、jQuery、原生小程序、uni-app 全都出现过。与其说这是一次技术盘点，不如说是一份"个人前端编年史"。趁着记忆还热，把关于框架选择的思考记下来。

一、先盘点：我的项目都用什么写的

技术栈	项目数	典型形态	典型特征
React 16	~20	云平台 B 端控制台、数据管理后台、视频管理后台等	某云厂商控制台体系，内部组件库 / antd 3，多个项目用 qiankun 微前端
Vue2	~11	物联网管理平台、中后台管理系统、练手项目	某开源低代码平台（ant-design-vue 1.x）为主，另有 element-ui 系
Vue3	~4	信息管理系统、可视化大屏	Vite + Pinia + element-plus / ant-design-vue 4，大屏用 three.js
Angular 5	1	某运营管理系统	Angular CLI 1.7 + PrimeNG + Bootstrap 3 + jQuery，孤例
uni-app	3	管理系统移动端、资源查询应用	小程序 / App / H5 多端
jQuery / 静态站	2	企业官网	纯 HTML + CSS + JS
原生小程序	1	某小程序	wxml / wxss

几个有意思的细节：

1. React 项目全部锁死在 16.x，没有一个 17/18；Vue2 全部是 2.6；连 Angular 也停在 5。
2. 同一个产品里同时存在 Vue2 和 React 两套前端目录——一次没做完的框架迁移的痕迹。
3. 同一套 Vue2 低代码平台底座被复制了至少 6 份，分别服务不同的交付项目。
4. jQuery 阴魂不散：不少 React 16 项目里还躺着 jquery@^3.5.1 的依赖。
5. qiankun 微前端同时出现在 React 和 Vue3 项目里——跨框架整合是刚需。

二、一条隐约的时间线

把这些项目按技术栈排开，能看到一条清晰的演进路径：

静态站/jQuery → Angular 5 → Vue2（学习期）→ React 16（工作主力）
     → Vue2（交付期）→ Vue3 + Vite（新项目）→ uni-app（多端）

• jQuery 时代：两个手写 HTML/CSS/JS 的企业官网，能用就行。
• Angular 尝试期：某运营管理系统是唯一一个 Angular 项目。Angular 5 + TypeScript 2.4 + PrimeNG，工程化齐全（Karma、Protractor、Codelyzer 都配了）。然后，就没有然后了。
• Vue2 学习期：一个 Vue 2.0 的 demo 商城、一个 Vue 2.5 + webpack 3 老脚手架项目，是入门练手的痕迹。
• React 工作期：进入某云厂商的机器学习平台团队后，内部组件库 + React 16 是控制台的标准答案，前前后后参与了近 20 个控制台子应用。
• Vue2 交付期：离开大厂体系后，开源低代码平台成了快速交付的底座，复制 6 份就是 6 个项目。
• Vue3 期：近年的新项目全部转向 Vue3 + Vite + Pinia + TypeScript。

三、各框架在我手里的真实定位

Angular：一次认真的尝试，然后转身

那个 Angular 项目配置齐全，显然不是随手玩玩。但它是孤例，之后再无 Angular 项目。回头看原因很朴素：

• 学习成本与收益不成正比。RxJS、DI、装饰器、模块体系，概念密度是 Vue 的好几倍，而写出来的中后台页面并没有比 Vue 快。
• 国内生态弱。招聘难、组件库选择少（当时主要靠 PrimeNG）、中文资料少。
• 大版本升级太痛。AngularJS → Angular 2 是重写，之后每个大版本都有 Breaking Change，"框架帮你做决定"的另一面是"你被框架推着跑"。

Angular 教会我的东西留下来了（依赖注入、RxJS 响应式思维，后来在 React 项目里用 redux-observable 时全用上了），但框架本身被放弃了。

React：B 端控制台之王，但它是"被选择"的

近 20 个 React 项目几乎全是工作产物。当时所在团队的整套云控制台基于 React + 内部组件库，入职第一天就没得选。但这套"没得选"背后有它的道理：

• 大型 B 端场景下，React 的灵活性是资产。控制台业务千奇百怪，自定义渲染、复杂表格、流程编排（有画布类需求），React 的"只是函数"心智模型兜得住。
• 生态最深。monaco-editor、echarts-for-react、react-dnd、final-form……控制台要用的重型组件，React 侧永远有最成熟的封装。
• TypeScript 一等公民。其中一个大型控制台是 CRA + TS，大型多人协作项目里类型就是文档。

代价也真实存在：状态管理从 redux → redux-saga → redux-observable → dva 走了个遍（有的项目里全家桶都有），心智负担不小；而且版本冻结在 16——不是不想升，是几十个存量子应用 + 微前端容器一起锁死了版本，谁也不敢先动。

Vue2：交付利器与低代码底座

Vue2 项目分两类：

element-ui 系：中后台 CRUD，Vue2 + element-ui 是那个年代的"人月神话"——一个熟练前端 + 一周 = 一个管理模块。

低代码平台系（复制了 6 份）：这是最值得琢磨的现象。为什么一个低代码平台被反复使用？因为在工期压死、需求琐碎、客户只看结果的交付场景里，"代码优雅"让位于"明天能上线"。表单、报表、权限、代码生成器都是现成的，改改就能交。

Vue2 的模板语法对非科班出身的同事也友好，团队里人人能改，这在外包/交付型团队里是决定性优势。

Vue3：新项目的默认答案

某管理系统前端（element-plus + Pinia + Vite + vxe-table）、某大屏项目（ant-design-vue 4 + qiankun + three.js + gsap）——所有 2023 年后的新项目无一例外选了 Vue3 + Vite。

原因不复杂：

• Vite 的开发体验是降维打击。从 webpack 3 分钟级冷启动到 Vite 秒级，回不去了。
• Composition API 解决了 Vue2 的真实痛点：逻辑复用从 mixin 地狱变成 hooks，@vueuse/core 这类生态直接受益。
• Pinia 比 Vuex 舒服一个量级。
• 存量 Vue2 项目的迁移路径清晰（低代码平台官方都出了 vue3 版），团队技能平滑过渡。

框架之外：不要忘记它们仍然存在

• 静态站：一个官网，9 个 HTML，何苦上框架？框架是成本，不是勋章。
• 原生小程序：单一微信端、页面少，原生开发反而最稳。
• uni-app：一个代码库同时出 H5 / 微信小程序 / Android App，与管理端组成整套系统。多端需求真实存在时，它是性价比之选；只做一端时，它就是负担。

四、几点思考

1. 框架常常不是"选"出来的，是"长"出来的

回头看，真正由我"自由选择"框架的项目屈指可数。进大厂团队，React 是既定事实；接交付项目，客户预算和工期决定了只能用低代码平台；做小程序，uni-app 是唯一能兼顾三端的现实选项。个人技术选型的自由度，远比技术社区讨论里想象的小。工程师真正的选择空间在于：在既定框架内把工程化做到什么程度，以及在框架之外（构建、规范、测试、监控）积累可迁移的能力。

2. 版本冻结是常态，不是事故

React 16 用了五年，Vue2 至今还在服役（当前这个项目就是），Angular 5 停在 2018。社区总在讨论"如何升级到最新版"，但真实世界的问题是"如何让老版本继续安全地跑"。框架升级从来不是技术问题，而是收益核算问题：升级 React 17/18 带来的收益，抵不上回归测试几十万行存量代码的成本，那就永远不升。接受这一点，反而会把注意力放到更值得的地方——比如把依赖锁死、把 CI 建起来、把文档写好。

3. 没有最好的框架，只有匹配场景的框架

把我的项目按场景重新归类，答案其实很整齐：

场景	最优解（我的实践）
大型 B 端控制台、多人长周期协作	React + TS + 企业级组件库
中后台交付、工期敏感	Vue2 + element-ui / 低代码平台
新项目（2023 后）	Vue3 + Vite + Pinia + TS
官网、简单展示页	静态 HTML，或者干脆不上框架
多端（小程序 + App + H5）	uni-app
超重交互可视化（大屏、画布、编辑器）	框架只做壳，three.js / monaco / 自研引擎是主角

选型的第一问不该是"哪个框架好"，而是"这是什么场景"。问错问题，就会得出"React 天下第一"或"Vue 简单易用"这种正确但无用的结论。

4. 微前端是存量时代的妥协艺术

qiankun 同时出现在我的 React 项目和 Vue3 项目里。它解决的不是技术问题，是组织问题：老应用不想重写、新应用想用新技术、多个团队各管一段。代价是复杂度翻倍（样式隔离、通信、公共依赖）。如果不是被存量逼的，没人应该主动选微前端——但被逼的时候，它是体面的出路。

5. jQuery 依赖是个隐喻

那些 React 16 项目里的 jquery@^3.5.1，多半是为了某个老插件（拖拽、上传、日期选择）顺手引入的。它是技术债，也是务实——重写一个稳定运行的老插件，风险远大于收益。项目里每一处"不优雅"，背后都可能是一次正确的取舍。评价代码要先问它诞生的约束条件。

五、如果今天再选一次

给自己立一份选型清单，以后新项目按这个走：

1. 先问场景：B 端 / C 端 / 多端 / 纯展示？生命周期三年还是三个月？谁维护？
2. 默认答案：需要长期演进的 Web 应用 → Vue3 + Vite + TS + Pinia；团队 React 背景深 → React 18 + Vite；多端 → uni-app；纯展示 → 静态站。
3. 组件库先行：先确定 element-plus / antd / arco 哪个覆盖需求最全，再定框架细节——B 端项目里组件库比框架更影响效率。
4. 低代码只在交付型项目用：用低代码平台时，清醒地知道你在用"可控性"换"速度"，生成出来的代码要有心理准备接手维护。
5. 不追新，但盯趋势：React 19 的 Server Components、Vue 的 Vapor Mode 都值得关注，但生产项目只上"团队里至少一半人搞得懂"的技术。
6. 把不可迁移的成本降到最低：业务逻辑与框架解耦（逻辑放 hooks/composables/store），框架只是视图层——这样下次"没得选"的时候，损失最小。

六、结语

Project 文件夹像一棵年轮：jQuery 是树皮，Angular 是早年的一根侧枝，React 和 Vue2 是两根主干，Vue3 是最新的年轮。框架会过时，但每一圈年轮里沉淀的东西——工程化习惯、组件设计思维、对"什么时候该造轮子、什么时候该用现成"的判断——是跨框架的。

框架选择这件事，年轻时以为是选"哪个更强"，现在明白是选"哪个最匹配当下的场景、团队和工期"。而比选对框架更重要的，是让自己无论被塞给哪个框架，都能快速产出可靠的东西。

这大概就是这 40 多个项目教给我的事。