4.1 项目需求分析：规模、复杂度、类型、性能与SEO
4.1 项目需求分析：规模、复杂度、类型、性能与SEO
本节摘要：项目需求是选型的地基——脱离需求谈框架优劣都是空谈。本节从项目规模、复杂度、项目类型、性能要求、SEO 要求五个角度建立需求画像，把"项目是什么"写成可决策的清单。每个角度都给出"怎么判断、影响什么、对应什么框架倾向"，让你拿到一张能直接填的需求画像表，为第 4.5 节的打分提供输入。
本节导读
阅读完本节，你应当能够：
- 从规模、复杂度、类型、性能、SEO 五个角度完成需求画像。
- 说出不同规模项目对框架结构能力的需求差异。
- 把项目类型（内容站/数据密集/实时/移动端）映射到框架与渲染模式倾向。
- 判断性能要求（首屏/运行时/内存）对应哪些框架特性。
- 完成一张可直接用于后续打分的"需求画像表"。
一、问题与直觉：同一个"商城"，是 3 个页面还是 300 个页面
"我要做个商城"这句话，信息量为零。是 3 个静态展示页的落地站，还是 300 个动态页面的全功能电商？前者可能连框架都不需要，后者要考量的是一整套工程能力。项目需求分析的全部意义，就是把"我要做个 X"这种模糊表述，逼问成"项目到底是多大、多复杂、多快、要不要 SEO"的具体数字与判断。
需求分析不是填表游戏，而是选型这条推导链的第一环——第 3 章八个维度给的是"怎么比"，本节给的是"拿什么比"。需求画像清晰了，候选框架会自动收敛：需求越明确，选型越不纠结。
💡 关键直觉：需求分析是"给项目称重"。你不需要称到克，但必须知道它是一头象还是一只猫——因为接下来的所有选型动作，都建立在这个重量级判断上。
二、核心原理：五个角度逐个拆
2.1 项目规模：小、中、大、超大
- 小型/原型：生命周期短、功能少，重开发效率与快速交付。倾向：Vue 或轻量方案。
- 中大型：需长期维护、功能复杂、用户量大，重稳定性、可扩展性、性能与社区。React/Vue/Angular 都是成熟选择，按具体需求细化。
- 超大型/微前端：单一框架难覆盖所有子模块，或存在历史遗留系统，需要微前端架构。此时重点看框架与微前端方案的兼容性、子应用通信能力（详见 5.7）。
2.2 复杂度：UI、业务逻辑、团队协作三个层面
- UI 复杂度：大量复杂交互、动画、可视化、自定义组件 → 组件化能力、状态管理、UI 库生态是重点。React/Vue 擅长，Angular 提供更完整方案。
- 业务逻辑复杂度：数据流转频繁、状态纠缠 → 数据管理方案（Redux/Vuex/Pinia/NgRx）是否强大、易维护是重点。
- 团队协作复杂度：多团队、多人并行 → 规范性、一致性是关键。Angular 的约定优于配置更适合大型团队，React/Vue 需要团队自定规范。
2.3 项目类型：内容、数据、实时、移动
| 项目类型 | 关键需求 | 框架倾向 |
|---|---|---|
| 内容展示站 | SSG/SSR、SEO、首屏 | Astro / Next.js / Nuxt |
| 数据密集应用 | 表格、图表、数据绑定 | Vue + ECharts / React + 组件库 |
| 实时交互应用 | WebSocket、状态实时更新 | React / Vue + 响应式状态 |
| 移动端 | PWA、跨端 | React Native / Ionic / PWA 方案 |
| 内部后台 | 表单、权限、规范 | Angular / Vue + Element Plus |
2.4 性能要求：首屏、运行时、内存
- 首屏加载：SSR/SSG、代码分割、Tree Shaking 是关键 → Next.js/Nuxt/Astro 有天然优势。
- 运行时性能：渲染机制与更新策略是重点 → React 的 memo、Vue 的依赖追踪、Angular 的 OnPush、Svelte 的编译期方案。
- 内存占用：资源受限环境（嵌入式）或长时间运行 → Svelte/SolidJS 这类少运行时方案更合适。
2.5 SEO 要求：爬虫能不能看懂
- 高 SEO 需求 → SSR/SSG 是硬需求，纯 CSR 基本淘汰（除非用预渲染兜底）。
- 中低 SEO 需求（登录后应用）→ CSR 完全够用，不必为 SEO 付出 SSR 的架构复杂度。
三、工程实践要点：一张能直接填的需求画像表
3.1 需求画像表模板
| 维度 | 问题 | 我的答案 |
|---|---|---|
| 规模 | 页面/模块数、团队规模、生命周期 | … |
| 复杂度 | UI/业务/协作哪个最复杂 | … |
| 类型 | 内容/数据/实时/移动/后台 | … |
| 性能 | 首屏/运行时/内存哪个是硬指标 | … |
| SEO | 是否需要搜索引擎收录 | … |
这张表是所有后续打分（4.5）的输入。填得越具体，打分越有据可依。
3.2 需求驱动选型的三条推导路径
路径一（内容站）：类型是内容站 + SEO 重要 + 首屏要快 → 直接排除纯 CSR 框架 → 候选收敛为 Astro / Next.js / Nuxt / VitePress。
路径二（内部后台）：类型是后台 + 表单密集 + 权限复杂 + 团队规模中 → 候选收敛为 Angular（强规范）或 Vue + Element Plus（快）→ 再用团队技能与招聘维度定胜负。
路径三（实时应用）：类型是实时交互 + 数据频繁更新 + 无需 SEO → 关注运行时性能与状态管理 → React/Vue/Svelte 都可进入决赛圈，用 POC 验证渲染性能。
3.3 常见需求误区
- "我们的项目会变得很大"：这句话不能证明你该选重型框架——"未来会大"是规划，得先有明确的增长路径与时间窗，否则就是为假想未来支付现时成本。
- "性能是我们的核心"：先确认性能是"已经量化的瓶颈"还是"听起来重要的原则"。前者有数据，后者是口号。
- "要支持多端"：多端需求要拆开：是同套代码（React Native/跨端方案），还是各端独立（不同技术栈），策略完全不同。
⚠️ 常见坑：把需求分析做成"给既定框架找理由"。先写完画像表、让团队对齐，再让框架进入讨论——顺序颠倒，需求分析就失去了意义。
3.4 需求分析的产出
需求分析结束时，你应该有两样东西：一张填完的需求画像表，以及一张被排除候选的清单（每条排除都附一个需求理由）。后者尤其重要——它证明了你的选型是被约束逼出来的，而不是被偏好带出来的。
3.5 需求画像的五步走：把"模糊想法"逼成"明确规格"
需求分析不是一次头脑风暴，是一套有顺序的逼问。第一步，问"项目到底是什么"：页面/模块清单、用户角色、核心流程——把产品讲成一个能走通的叙事。第二步，问"它现在多大、三年后多大"：从规模预期推导出结构需求（是否需要模块化、微前端、SSR）。第三步，问"它怎么被使用"：访问设备、网络环境、使用频率——推导出性能与移动端需求。第四步，问"它要不要被看见"：SEO 需求决定渲染模式。第五步，问"谁来做、多久做完"：团队规模与时间窗决定学习成本与流程重量级。五步走完，之前"说不清的需求"全部落成可勾选的项——这五步看似繁琐，却是防止"选完框架才发现需求理解偏了"的最便宜手段。需求理解偏差是选型失败的最常见原因，而它几乎总是因为跳过了这一步的某一问。
3.6 一个易被忽视的维度：需求的"变动性"
需求画像不仅要画"今天的项目"，还要给"明天的项目"留个问号：需求变动有多频繁？方向调整的可能性有多大？这个问题的意义在于：变动性高的项目，选型的重点要从"选对方案"转向"选易改方案"——框架的灵活性、渐进式采用能力、生态的丰富度（改需求时能快速找到新方案）权重会上升。反之，需求稳定、长期不变的项目，可以把权重压在性能与维护性上。把"变动性"作为一个显式问题放进需求分析，能避免一个常见悲剧：花大力气选了个"最优解"，结果需求一变，最优解变成了最僵的解。
3.7 需求分析的两个"最容易翻车"的细节
需求分析里有两个细节经常被忽略，却最容易导致选型翻车。细节一：把"用户"与"客户"混为一谈。客户是付钱的人（B 端老板），用户是天天用的人（C 端操作员），两者的需求常常冲突——B 端要功能全，C 端要简单。选型要服务"用户"的日常使用体验，同时满足"客户"的功能清单，需求画像要分别记录两类角色的核心诉求。细节二：把"性能要求"写成形容词。需求表里写"性能要好"等于没写；应该写成可测量的数字（如"首屏 2 秒内"、"列表滚动 60 帧"、"包体积 200KB 内"）。可测量的需求才能指导选型与验收——写不出数字的性能需求，多半是还没想清楚。这两个细节看似小，却是需求分析质量的分水岭：把它们处理好的团队，选型的地基是实的；没处理的，后面每一步都在流沙上盖楼。
3.8 需求分析的"证据收集"：别只靠产品经理一句话
需求分析最忌讳的，是只依据"产品经理嘴里的需求"就做判断。更稳的做法是为每个关键需求收集证据：数据（页面访问量、留存率、转化漏斗）、用户反馈（客服记录、用户访谈）、竞品对比（同类产品怎么做的）。为什么要这么较真？因为"需求"会撒谎——它经常被表述成"老板想要的"而非"用户需要的"，被表述成"听起来合理"而非"被验证过"。一个没有证据支撑的需求（比如"我们要做成 Facebook 一样的产品"），会让选型建立在想象上。给每条关键需求标一个"证据等级"（数据证明 / 用户反馈 / 竞品参考 / 老板判断），需求分析就从"记录愿望"变成"评估愿望"——而选型质量，永远取决于它站在什么证据等级的地基上。
3.9 一个需求分析的收尾动作：写出"需求给选型的任务书"
需求分析做完后，最后做一个收尾动作：把画像表翻译成"给选型的任务书"——用三到五句话写明"这个项目要求技术方案必须做到什么"。示例：任务书可能写"必须支持 SSR 以满足 SEO；必须能在 3 个月内让零 React 经验的团队上手；必须能支撑未来千万级访问的扩展；必须兼容现有后端技术栈"。这份任务书把需求从"描述"变成"验收标准"，是需求与选型之间的桥梁——第 4.5 节的权重分配、POC 用例设计，都直接从这份任务书推导。没有任务书的选型，评估维度再多也容易跑偏；有了任务书，八维评估就变成了"对照任务书逐条打分"的工程题。把它写出来、贴在团队评审的第一页，整个选型就有了明确的靶子。
本节速览
- 要点一：需求分析五角度：规模、复杂度、类型、性能、SEO。
- 要点二：规模决定结构需求，复杂度决定数据流需求，类型决定渲染模式。
- 要点三：性能要求要区分首屏/运行时/内存，各自对应不同方案。
- 要点四：SEO 是硬约束，高 SEO 需求基本排除纯 CSR。
- 要点五：产出是"需求画像表 + 排除清单"，不是"喜欢的框架清单"。
- 要点六：需求越明确，选型越不纠结——分析是整条推导链的第一环。
项目画像清楚了，接下来看"谁会做它"——团队技能评估，别让框架决定团队命运。