10.2 框架对比总表：Solid、React、Vue、Svelte

10.2 框架对比总表：Solid、React、Vue、Svelte

本节摘要：全册的对照在两个坐标上展开——"有没有虚拟 DOM"与"响应式发生在运行时还是编译期"。本节把四个主流方案摆进这两个坐标，再沿五个维度给出总矩阵，把前九章散落的结论收拢成一张可以带进选型会的图。

技术选型的比较表容易写成参数罗列，本节反着来：先把四个方案放进两个真正的结构性坐标，让位置解释特性，再列维度表供查阅。看完你应当能对矩阵上任意一格给出技术依据，而不是转述评测结论。

两个结构性坐标

坐标一是"更新前要不要先描述"：React 与 Vue 每次更新先生成虚拟 DOM 描述再对账；Solid 与 Svelte 不生成描述，直接定向改节点。坐标二是"依赖关系谁说了算"：Solid 与 Vue 在运行时动态收集依赖（前者靠读取现场，后者靠 Proxy 拦截）；Svelte 把依赖分析放到编译期，信号性语言标记静态可判；React 干脆没有依赖收集——依赖就是"整个组件函数"，粗到不需要收集。

图：四框架的结构坐标定位

位置直接解释行为。React 在左上：既要付对账的开销，又因依赖粗而付重渲染的开销，换来的是"随时整组件重算"的极简心智。Vue 也在左上但靠编译优化与细粒度依赖把账单打折。Solid 在右上：运行时依赖图加直改节点，两个坐标都取了细粒度一端。Svelte 在右下：直改节点这一点与 Solid 同侧，但依赖判定交给编译器，运行时图最薄——代价是动态场景下编译器判不准时要退回运行时机制。

五维总矩阵

基准行需要配一句免责：量级是多轮中位的概述，同框架不同版本与配置会有浮动，用途是分组不是排名。心智负担行的公允说法：Solid 的负担集中在"追踪规则"一条线上，学透一条线之后不再有散点；React 的负担是分散的——依赖数组、memo、引用稳定、闭包旧值，每一处都可能咬人。

选型的三条短判断

判断一：团队超过五十名前端、组件库与内部基建深度绑定 React 生态，迁移的组织成本会吞掉技术收益——留。判断二：新绿地项目、界面交互密集、目标设备广（含弱机与嵌入式 WebView），Solid 的运行时优势直接变现——选。判断三：内容为主、交互浅的站点，任何现代框架的差距都被静态化抹平，按团队熟悉度选即可——不必为框架焦虑。这三条不覆盖所有情况，剩余情况交给 10.4 的决策路径。

💡 一个检验选型思考质量的问题：如果你给的理由是"某某更快"，追问一句"快在哪一桶、你的应用高频操作是不是那一桶"。答不上来，说明理由还是传闻；答得上来，你的选型才有了工程依据。

深读一格：React 为什么不走向细粒度

矩阵的 React 格常引发"为什么不改"的疑问，值得替 React 说清约束。历史包袱：百万级存量应用与整个组件生态建立在重渲染模型上，运行时语义的任何改动都是生态级风险，官方宁可加层（编译器、服务端组件）也不动地基。模型收益：整组件重跑的模型简单到可以一句话讲清，支撑了它最宽的教育与招聘基座；把"状态到界面"写成纯函数也让时间旅行、并发特性有清晰的介入点。并发特性：可中断的对账需要"整棵描述树"这个统一的工作单元，细粒度图反而是障碍。所以 React 的进化方向是给现有模型加外挂降负（自动记忆化、服务端组件），而非换模型——理解这一点，矩阵上那一格就从"落后"变成了"另一种自洽"。

给三类团队的路线建议

矩阵落到组织上，给三种典型团队各一句路线。初创三五人团队：按产品形态在 Solid 与 React 里二选一即可，切换成本低是你们最大的特权，选型会别超过一次午餐。三十人上下、多产品线的团队：允许技术栈多元，新线按 10.4 决策，旧线保持稳定，把对照体系（本册）作为内部分享材料而非迁移动员令。数百人平台型组织：框架即基建，迁移是数年工程，把精力放在基建对多框架的兼容层上——构建、监控、组件规范——让业务线保有选择权。

本节要点回顾

• 两坐标定位法：描述层与依赖层的取舍决定一切行为差异，位置先于特性。
• 四象限都有居民：每个象限都是一组合理取舍，没有全维度赢家。
• 负担形态不同：React 的负担是散点，Solid 的负担是单线，学习曲线形状因此不同。
• 基准用于分组：量级参考匹配场景，不做小数点排名。

问题：四个框架会收敛成一个吗？

不会收敛成一个框架，但正在收敛在一套语义上——Signals 提案是明证（10.3 展开）。视图层的外壳（模板语法、组件组织、构建形态）大概率长期多元，因为它们承载的是社区文化与人机界面偏好，不是纯技术问题。对工程师的含义：视图层技能会继续"逐框架失效"，响应式语义技能持续保值，学习投资该往后者倾斜。这也解释了本册为何把大部分篇幅押在语义层而非工具层。

矩阵的用法：对照阅读你的代码库

这张矩阵最有价值的用法不是背结论，而是拿它审自己的代码。抽三个你最有把握的组件，问四组问题：状态放在什么原语里，为什么（对到第 2 章）；组件函数被谁、以什么频率执行（对到第 3 章）；一次数据变化从发出到界面生效，路径上有几步（对到第 4 章）；复用单元是什么形态，拆分依据是什么（对到第 5 章）。四个问题在你的框架里都答得干脆，说明你对现有技术栈的理解已经到位；再读另外三个框架的对应答案，迁移或选型的判断材料就备齐了。矩阵是镜子不是考卷——照自己，比照别人有用。

下一章看时间轴——这些结构性差异正在如何走向趋同，以及 Solid 自己往哪走。