1.3 按业务场景选择框架
1.3 按业务场景选择框架
本节摘要：选框架不是比流行度，而是拿"场景约束"去筛掉不合格的方案。把团队、生态、遗留代码、性能诉求四类约束依次排开，你既能拍板"这个项目用 Vue"，也能说出为什么不是另一个。本节给出一条可重复执行的选型决策流程。
本节阅读目标
阅读完本节，你应当能够：
- 列出决定框架选择的四类关键约束。
- 对给出的具体场景，走完"约束 → 淘汰 → 拍板"的流程。
- 识别并避开"因为别人都用所以我也用"的跟风陷阱。
一、选型错误的真实代价
选错框架的代价是隐性的：团队学得慢、第三方库到处找补、后期跨版本迁移要重写大量组件。而大多数人恰恰在"刚上手、信息最少"时做决定——这是完完全全的反向高峰。与其临阵抓瞎，不如在动手前把约束摊开。
二、四类决定性的约束
把判断权交给客观约束，而不是主观感受。下面是四组在比稿评审时最先摆上桌的条件。
团队约束（权重最高）
前端最重要的资产是"谁能长期维护"。团队熟 React 就选 React，哪怕功利地说，学习成本比任何技术优势都更决定项目命运。团队全新的项目，Vue 的模板式写法往往推进更快。
生态与招聘约束
需要大量现成组件库、招聘池大，React 的生态体量是加分项；反过来，项目常用官方全家桶、希望少做组装决策，Vue 的官方方案更省心。
遗留代码与迁移约束
接手的项目已有大量旧组件，迁移成本要仔细掂量。给旧 React 项目补人，新手补进 Vue 团队就想重写重来，这些都是隐藏否决项。
性能与深度定制约束
绝大多数业务两种框架都性能够用。只有极端长列表、高频更新这类场景才需要深挖机制。在启动前先确认"是不是真遇到了性能悬崖"，别拿想象出来的需求当约束（更多机制对比见 2.2、2.3）。
三、选型决策流程
把上面四类约束演成一条可重用的决策线：
图：基于场景约束的选型决策流
一个完整走查：选了还是没选
用一个贴近现实的中型项目走一遍，就看得出这套流程"怎么贴合"，而不是纸上谈兵。假设你所在的电商团队要二次开发一个后台管理台：现有代码是基于 Element（Vue 生态）搭的，五个前端里四个熟 Vue、一个会 React，之后要接十几个现成的图表与权限组件，性能上只是普通 CRUD、几十个列表页面，没有任何高频刷新。
按四类约束过一遍：团队约束下，四人熟 Vue 是压倒性条件，选 React 要重新培训；生态约束下，后台本就堆的是 Vue 官方全家桶和 Element 组件库，迁移成本高；遗留约束下，旧的后台代码几乎全部可复用，重写等于推倒刚做的稳定功能；性能约束下，普通后台完全不构成瓶颈。四轮走完只剩 Vue 一个候选——这不是"Vue 更好"这类空泛结论，而是每一轮都在"淘汰不合格方案"。
再设想同一个人去评估一个全新的、要上微信小程序且大量自绘图表、团队六个全熟 React 的组。这会四轮都往 React 倒。同样一个工程师，在两个场景里给出两个相反的结论，恰恰证明这套流程不是拍脑袋——约束不同，答案自然不同。这正是比稿评审的核心：先立标准，再评方案，最后才谈喜欢不喜欢。
四、三个容易糊弄的"假约束"
- "X 比 Y 快"：没有具体的业务负载与基准，这句话没有决策价值，多数是炒作。
- "看榜单它最火"：流行度反映的往往是存量市场与生态完善，不等于适合你的项目。
- "大家都用，错不了"：跟风是对技术判断力的放弃，真到迁移时没人替你兜底。
四·一、把四类约束落成一张"淘汰表"
四类约束说清楚了，但怎么"同时"叠加判断仍容易乱。一个可落地的做法是把它们摊成一张淘汰表：每一行是一项约束，每一列是一个候选框架，在交叉格填"过/存疑/否"。整理表的过程中，你会发现很多纠结自动消失，因为约束会自己淘汰掉不合格者。
约束维度 | Vue | React | 备注 团队可维护性 | 通过 | 存疑 | 四人熟、一人会——React 培训成本高 生态与组件库 | 通过 | 通过 | 后台现成组件充足 遗留代码迁移成本 | 通过 | 存疑 | 旧口径基于 Element 重写风险高 性能与深度定制 | 通过 | 通过 | 普通 CRUD，无高频刷新 结论 | 采用 | 暂缓 | 团队约束是压倒性否决项
这张表的价值不在最终结论，而在"存疑"那一格逼你去说清到底担心什么、能否接受。假如你是那个"会 React"的第四个人，你该主动接哪一格？多半是团队那一行——要么补 Vue 技能，要么独自扛起 React 侧重写，而后者往往比想象贵得多。把存疑项暴露出来，才谈得上"因为所以"地评审，而不是拍脑袋地站队。
五、比稿结论怎么写
把选型结论写成"因为所以"，而不是一句断言。"因为团队三人都熟 React、项目需要大量三方图表库、且旧系统是 React，所以选 React"——这条结论清晰、可复核、能被下一次评审审视，这正是整套教程在"组件复用比稿现场"里反复练习的表达方式。
两难场景：两边仿佛都行怎么办
比稿流程常常会走到"团队都熟、生态都够、遗留不背锅"这种看似两可的境地——这时选型反而最容易糊涂。经验是别再在两个候选的优缺点上空转，而是追加三种"破场"武器。一是"启动一个两周的原型"：让最贴近现场的人各搭一版，用真实渲染的体感补上用榜单和文档填不平的信息差。二是"看两到三年内的团队方向"：如果公司未来要做小程序套壳或轻应用，Vue 的渐进式与官方全家桶往往衔接更顺；如果更偏大型协作与复杂交互研发，React 的生态吞吐力更可靠。三是"承认可用足够、转向风险最小"：当两个方案都能交付，就选那个迁移成本最低、团队更放心的——技术选型的最高境界不是选赢，而是选完团队愿意持续维护下去。
本节要点回顾
- 排序：团队约束 > 生态/遗留/性能，别把次要因素当首位。
- 可重复流程：约束 → 淘汰 → 拍板，形成可复核的"因为所以"结论。
- 醒三件假约束：无基准的速度论、流行榜单、跟风随大流。
- 一个信号：选型结论说不清理由，往往意味着你被偏见推着走。
如果说第 1 章回答"我该扛哪把枪"，那么从第 2 章起，我们开始研究这把枪的内部构造。下一步进入通用核心原理：组件化的本质、虚拟 DOM、响应式、生命周期。