技术选型
技术选型是项目的地基决策，选错了后期改造成本极高。原则：业务为出发点，而不是为了用新技术而用。
子章节导航
本章节包含以下内容，建议按顺序阅读：
- 页面渲染模式（强烈推荐先看）— 选型决策里权重最大的一环，决定框架、部署、SEO 策略
- 技术调研 — 如何做一份合格的技术调研
- 方案设计 — 如何写一份完整的项目方案设计文档
选型清单
- 框架：React / Vue / ...
- 语言：TypeScript（强推） / JavaScript
- 构建工具：Vite / webpack5 / ...
- 包管理器：pnpm / yarn / npm
- 路由：react-router v6 / vue-router v4
- 状态管理：Redux / MobX / Zustand / Pinia
- UI 库：Ant Design / Element Plus / ...
- 请求库：axios + 二次封装
- 工具库：lodash / ahooks / ...
- 样式方案：less + css module / styled-components
- 代码规范：ESLint + Prettier + Stylelint
- 提交规范：Husky + lint-staged + Commitlint
- 测试：Jest + React Testing Library
- CI/CD：GitHub Actions / Jenkins
一、选型考虑维度
| 维度 | 关注点 |
|---|---|
| 团队 | 人力成本、上手成本、现有技术栈储备 |
| 业务 | SEO、性能、跨端、交互复杂度 |
| 生态 | 社区活跃度、第三方库丰富度、招聘市场 |
| 兼容 | 浏览器/Node 版本、SSR/SSG、移动端 |
| 长期 | 维护方稳定性（库是否还在维护）、迁移成本 |
小团队尽量统一技术栈，降低协作成本。选 1-2 个主语言、1 个 UI 库、1 个状态管理。
二、框架
框架是地基决策，后期迁移成本极高。
| 框架 | 生态 | 学习曲线 | 适用 |
|---|---|---|---|
| React | 最丰富（国内稍弱于 Vue） | 中 | 通用首选，海外项目 / 大型应用 |
| Vue | 国内最丰富 | 低 | 国内中小团队首选，上手快 |
| Svelte | 小 | 低 | 极致性能、编译时优化 |
| SolidJS | 小 | 中 | 接近 React 的开发体验 + 极致性能 |
选型建议：国内业务优先 Vue，中后台/海外优先 React。Svelte / SolidJS 是"小而美"的选择，生态和招聘是硬伤，慎用于生产。
三、渲染模式
完整内容请看 《页面渲染模式》——本节只放速查表，方便快速回忆。
| 模式 | 渲染时机 | SEO | 首屏 | 服务端压力 | 部署复杂度 | 一句话定位 |
|---|---|---|---|---|---|---|
| CSR | 浏览器 | ❌ 差 | ❌ 慢（白屏） | ✅ 几乎为零 | ✅ 极简（纯静态） | 反 SEO 的纯前端 |
| SSR | 请求时 | ✅ 好 | ✅ 快 | ❌ 高（每请求渲染） | ❌ 需 Node 运行时 | SEO + 实时数据双雄 |
| SSG | 构建时 | ✅ 极佳 | ✅ 极快 | ✅ 几乎为零 | ✅ 极简（纯静态） | 部署最便宜的 SEO 方案 |
| ISR | 构建时 + 按需再生 | ✅ 好 | ✅ 快 | 🟡 低（仅失效时） | 🟡 需 Node 运行时 | SSG + SSR 的折中 |
| RSC | 请求时 | ✅ 好 | ✅ 快 | 🟡 中（仅 RSC 部分） | 🟡 需 Node 运行时 | 数据密集型应用首选 |
| Astro Islands | 构建时 + 按需 hydrate | ✅ 极佳 | ✅ 极快 | ✅ 几乎为零 | ✅ 极简（纯静态） | 文档+工具混搭站首选 |
容易混淆的两个概念：
- SPA（Single-Page Application）是架构形态，整个应用只有 1 个 HTML，靠前端路由切换
- CSR/SSG/SSR 是渲染模式，判断首屏 HTML 怎么生成
- 二者正交：Next.js 用了
next/link是「SPA 体验 + SSG/SSR 渲染」的典型例子
详细对比、MPA vs SPA 概念澄清、6 种模式优缺点分析 → 跳转 页面渲染模式 全文。
四、构建工具
| 工具 | 语言 | 适用 | 特点 |
|---|---|---|---|
| Vite | Go (dev) + Rollup (prod) | 新项目首选 | 启动 < 1s、原生 ESM |
| webpack 5 | JS | 老项目、大型工程 | 生态最丰富、配置复杂 |
| Rollup | JS | 类库开发 | 产物干净、tree-shaking 友好 |
| esbuild | Go | 速度敏感场景 | 极快但 API 简单 |
| SWC | Rust | 替换 babel/tsc | 速度比 babel 快 5~10x |
| Turbopack | Rust | Next.js 生态 | 还在迭代中 |
| Rspack | Rust | webpack 替代 | API 兼容 webpack，迁移成本低 |
选型建议：新项目 → Vite；已有 webpack 项目保持 + 局部 swc 加速；类库 → Rollup。
四、状态管理
| 方案 | 适用 | 特点 |
|---|---|---|
| Context | 简单全局、主题、locale | React 原生，性能一般 |
| Redux | 大型、复杂业务、需时间旅行 | 模板代码多、生态完备 |
| MobX | 响应式偏好、OOP 风格 | 代码少、基于 Proxy 自动追踪 |
| Zustand | 中小型项目 | 轻量、hooks 风格、3KB |
| Jotai | 原子化状态 | 适合细粒度更新 |
| Valtio | 简化 MobX | Proxy + immutable |
| XState | 复杂状态机 | 状态可视化、测试友好 |
现代项目首选 Zustand / Jotai，复杂业务再用 Redux/MobX。
五、UI 组件库
| 框架 | 主流 UI 库 |
|---|---|
| React | Ant Design、Material UI、Chakra UI、shadcn/ui |
| Vue | Element Plus、Naive UI、Ant Design Vue |
| 跨端 | TDesign（腾讯）、Arco Design（字节） |
按需引入：babel-plugin-import、unplugin-vue-components、vite-plugin-style-import。
六、微前端
| 方案 | 特点 | 适用 |
|---|---|---|
| iframe | 隔离最彻底 | 嵌入式页面、老系统迁移 |
| single-spa | 最早的微前端框架 | 学习成本略高 |
| qiankun | 基于 single-spa，国内最流行 | 多技术栈共存 |
| Module Federation | webpack5 原生 | 构建期共享模块 |
| micro-app / wujie | 基于 web components | 接入简单、京东方案 |
| Vite Plugin Federation | Vite 生态 | 现代化选择 |
与 npm 包区别：npm 包是编译时共享（强耦合、性能最优），MF 是运行时共享模块（独立发版、配置复杂），微前端框架是整应用级运行时隔离（完全异构、基础设施重）。优先用 npm 私有包 / monorepo，有独立部署诉求再上 MF，最后才考虑微前端框架。
七、其他
类型系统
- TypeScript：现代前端必备
包管理
- pnpm：推荐，节省磁盘、安装快
- yarn / npm：兼容性好
跨端
- React Native / Expo：移动端
- Flutter：移动端
- Taro / uni-app：国内小程序
- Electron / Tauri：桌面端
- PWA：轻量级移动端方案
八、选型 checklist
- 业务场景是否真的需要这个技术？（KISS 原则）
- 团队有足够的学习时间吗？
- 社区活跃、最近一次发版在 6 个月内？
- 性能数据是否有 benchmark 支撑？
- 退出成本如何？是否容易迁移？
九、面试高频
- Q：为什么选 Vite 而不是 webpack？ A：Vite 利用浏览器原生 ESM，开发时按需编译，启动 < 1s；生产用 Rollup 产物质量有保障。webpack 配置生态成熟，但启动慢。
- Q：什么时候用 Redux，什么时候用 Zustand？ A：多人协作的大型项目、复杂异步流、需要时间旅行调试 → Redux；中小项目、追求简洁 → Zustand。Redux 模板代码多，新项目不建议直接上。
- Q：微前端的代价？ A：基础设施成本（qiankun、Module Federation 都需要改构建）、调试复杂度上升、版本管理混乱。除非真的需要多团队独立交付，否则谨慎使用。