前端框架选型
框架选型很少是“谁最强”这种问题，更常见的是：当前项目需要什么运行方式，团队已经熟悉哪套心智模型，后面准备承受多少工程复杂度。
先按问题来分
1. 先选渲染和运行环境
- 纯前端单页应用：React、Vue、SolidJS 都可以进入候选
- 需要 SSR、静态生成或全栈路由：先看 Next.js
- 需要企业后台、约定式路由和现成工程方案：先看 Umi
- 需要移动端原生应用：先看 React Native
- 需要跨端或小程序生态：先看 UniApp、小程序
- 需要桌面端应用：先看 Tauri、Electron
- 需要浏 览器扩展：先看 Plasmo
2. 再选团队更顺手的开发方式
- 偏函数式和生态灵活：React
- 偏模板直观和约定清楚：Vue
- 偏极简响应式和编译优化：SolidJS
常见方案怎么判断
| 方案 | 更适合什么场景 | 优点 | 代价 |
|---|---|---|---|
| React | 组件体系复杂、生态组合度高的项目 | 生态最大、灵活、资料多 | 自由度高，规范需要自己补齐 |
| Vue | 中后台、内容站、团队协作导向项目 | 上手快、模板直观、官方体系完整 | 超大项目里工程约束通常要额外设计 |
| Next.js | 需要 SSR、SSG、RSC、全栈路由的 React 项目 | 路由、数据获取、服务端能力整合得更完整 | 心智模型比纯 React 更重 |
| SolidJS | 追求轻量、响应式细粒度更新 | 性能好、写法简洁 | 生态和团队经验通常不如 React/Vue |
| React Native | React 团队进入 iOS / Android | 组件心智延续 React，跨端复用度高 | 真机调试、原生依赖和构建链复杂度会上来 |
| Umi | 企业后台、约定式工程体系 | 路由、插件、权限体系收得比较整 | 灵活度不如从零搭工程 |
| UniApp | 一套代码覆盖多端 | 跨端效率高、生态成熟 | 端能力差异和调试体验要额外适应 |
| 小程序 | 微信生态、原生能力优先 | 接近平台原生能力、上线链路成熟 | 技术栈割裂，复用边界明显 |
| Electron | 成熟桌面端应用 | 生态成熟、资料多、系统能力广 | 安装包和资源占用通常更重 |
| Tauri | 更轻的桌面端或桌面/移动混合路线 | 体积小、权限边界清楚、前端栈自由 | 需要接受 Rust 和更分层的调试链路 |
| Plasmo | 浏览器扩展开发 | 工程体验好，扩展场景支持完整 | 主要服务插件生态，通用性有限 |
更直接一点的选法
- 需要最大生态和长期招聘友好度：React
- 需要更低心智负担和更顺的上手路径：Vue
- React 项目还要补上服务端能力：Next.js
- 做企业后台且希望工程约束更多：Umi
- 做移动端原生应用：React Native
- 做跨端应用：UniApp
- 做桌面端应用：先在 Tauri 和 Electron 之间选
- 做浏览器扩展：Plasmo
常见误区
1. 把框架和工程方案混成一层
React、Vue 更像框架本体；Next.js、Umi、UniApp 更像在框架之上再包一层工程方案；React Native、Electron、Tauri 则更接近目标运行平台本身。把这几类东西拆开看，很多选型问题会简单很多。
2. 只按流行度选
流行度只能说明生态活跃，不代表每个项目都该选同一套。运行环境、部署方式、团队经验，通常比热度更关键。
3. 一开始就追求“万能方案”
多数项目都有明确边界。内容站、后台系统、跨端项目、插件项目，本来就不是同一类问题。先按场景收窄，再谈细节更省力。
Next.js 相关补充
如果已经确定方向是 Next.js，建议继续补这几篇：
推荐阅读顺序
- 先看这篇选型页
- 再进入当前项目真正对应的主框架
- 最后补路由、Hooks、版本升级和生态专题