重服务端还是重客户端，现代Web 应用架构如何选？

几十年来，Web 架构一直遵循着一个熟悉的模式：一种主导方法出现，获得近乎普遍的采用，在现实世界的规模下暴露出缺陷，最终被一种新的“最佳实践”所取代，而后者承诺修复前者破坏的一切。

我们在 2000 年代初见过这种情况，当时服务端渲染的单体应用是默认选择。我们在 2000 年代末和 2010 年代初又见了一次，那时转向富客户端应用。而在单页应用（SPA）崛起期间，这一点表现得最为明显：它们承诺在浏览器中提供桌面般的交互性，但往往交付的却是完全不同的东西：数兆字节的 JavaScript 捆绑包、空白的加载屏幕，以及为了让页面可被搜索发现而不得不进行的长达数年的 SEO 变通方案。

如今，服务端渲染再次流行起来。团队是否因为客户端架构已撞墙而转回服务端？不完全是。

服务端渲染和客户端方案在今天都一如既往地具有吸引力。现在的不同之处不在于工具或其可行性，而在于我们正在构建的系统以及我们对它们的期望。

结果是什么？再也不存在构建 Web 应用的单一“正确”模型了。 让我解释一下原因。

从网站到分布式系统

现代 Web 应用不再仅仅是“网站”。它们是长寿的、高度交互的系统，跨越多个运行时、全球内容分发网络、边缘缓存、后台工作进程以及日益复杂的数据管道。人们期望它们能瞬间加载，在网络条件不佳时保持响应，并在出现问题时优雅降级。

在这种环境下，架构上的教条主义很快就会成为一种负担。像“一切都应该服务端渲染”或“所有状态都应该在浏览器中”这样的绝对论调听起来很果断，但它们很少能在生产系统的考验中幸存下来。

现实要混乱得多。但这并非失败，而是反映了 Web 已经多么成熟。

架构绝对论已经过时

强烈的观点很有吸引力，尤其是在大规模应用中。它们能减少决策疲劳，让新员工入职更容易。宣称“我们只构建 SPA”或“我们是一个 SSR 优先的组织”感觉像是一种策略，因为它消除了模糊性。

问题在于，真实的应用程序并不配合。

一个现代 SaaS 平台通常包含截然不同的工作负载。面向公众的落地页和文档要求快速的首次内容绘制（FCP）、可预测的 SEO 行为以及激进的缓存策略。另一方面，经过身份验证的仪表盘可能涉及实时数据、复杂的客户端交互和长生命周期的状态，在这种情况下，每次 UI 变更都进行服务器往返是不可接受的。

试图在所有这些场景中强制推行单一的渲染策略，会引入许多团队最终意识到的“架构摩擦”。例外情况悄然出现，“就这一次”的逻辑开始盛行。随着时间的推移，这种架构变得比从一开始就明确承认这些权衡更难理解。

不是回到过去，而是扩展

将当前对服务端渲染的兴趣描述为“回归基础”是很诱人的。但在实践中，这种比较很快就不攻自破。

经典的服务端渲染应用运行在短暂的请求生命周期上。服务器生成 HTML，发送给浏览器，然后在下一个请求到来之前基本上忘记了用户。交互意味着整页刷新，状态几乎完全保存在服务器上。

现代服务端渲染应用的表现则大不相同。初始 HTML 往往只是一个起点。它会被水合（Hydration）、增强，并由在首次渲染后接管的客户端逻辑保持活跃。服务器不再拥有完整的交互循环，但它也没有消失。

即使是那些从未放弃服务端渲染的生态系统（PHP 是最明显的例子），也继续蓬勃发展，因为它们很好地解决了某些问题：提供了可预测的执行模型、直接的部署方式以及与数据的邻近性。发生变化的不是它们的相关性，而是人们的期望：现在它们应与更丰富的客户端行为共存，而不是相互竞争。

这不是回滚。这是架构版图的扩展。

混合架构不是妥协而是平衡

一旦团队摆脱意识形态，对话就会变得更有成效。问题从“什么是最好的模型？”转变为“我们现在要优化什么？”

数据变动频率很重要。每周变化一次的内容与实时、个性化的数据流表现截然不同。性能预算也很重要。在电子商务流程中，100 毫秒的延迟可能直接转化为收入损失。而在内部管理工具中，同样的延迟可能无关紧要。

运营现实也起着作用。有些团队可以舒适地运行和监控一群 SSR 服务器。而其他团队则更适合采用静态优先或无服务器方案，仅仅因为那是他们的人力和专业知识所能支持的。

这些压力很少在整个应用中均匀分布。具有严格正常运行时间要求的系统甚至可能选择在多层复制逻辑以减少耦合和故障影响，例如，同时在 API 边界和客户端强制执行关键验证规则，这样单个后端故障就不会完全阻塞用户工作流。

在这种背景下，混合架构不再是一种妥协。它们成为了一种让权衡变得明确而非偶然的方式。

当服务器承担更多 UI 责任时

近年来一个微妙的转变是，在浏览器变得具有交互性之前，服务器承担了多少责任。

这远远超出了 SEO 或更快的首次绘制。服务器生活在可预测的环境中。它们拥有稳定的 CPU 资源，并能直接访问数据库和内部服务。相比之下，浏览器的运行环境千差万别，从高端台式机到网络不可靠的低配移动设备。

越来越多的团队利用服务器来完成繁重的工作。服务器不再是发送碎片化数据让浏览器去组装，而是准备UI 就绪的视图模型。它聚合数据、解析权限，并以一种在客户端重复执行会昂贵或冗余的方式来塑造状态。

当负载到达浏览器时，客户端的任务变得更窄：激活并增强。这减少了可交互时间，并减少了发送给用户的转换逻辑量。

这自然导致了增量式和选择性水合。水合不再是一个全有或全无的步骤。关键的、首屏以上的元素首先变得可交互。较少使用的组件可能要等到用户与之互动时才会水合。

在这种模型中，性能优化变成了局部化而非全局化。团队可以在不重构整个应用的情况下改进特定的视图或工作流。渲染变成了一个分阶段的过程，而不是一个二元的选择。

可调试性重要性不断提升

随着应用变得更加分布式，性能不再是塑造架构的唯一关注点。可调试性变得越来越重要。

在简单的系统中，故障更容易追踪。渲染发生在一个地方。日志讲述了一个清晰的故事。在现代应用中，渲染可能分布在构建管道、边缘运行时和长生命周期的客户端会话中。数据可以在不同的时间点被获取、缓存、转换和重新水合。

当出现问题时，最困难的部分往往是找出哪里出了问题。

这就是分阶段架构显示出真正优势的地方。当渲染职责明确时，故障往往更加局部化。格式错误的初始渲染指向服务器层；看起来正常但在交互时失败的 UI 则暗示了水合或客户端状态问题。在架构层面，这反映了应用于单个类之外的单一职责原则：每个阶段都有明确的变更理由，以及在出问题时明确的调查地点。

那些试图用“自动”抽象来隐藏这种复杂性的架构，往往使调试变得更难，而不是更容易。工程师最终不得不逆向工程框架的行为，而不是推理系统设计。难怪许多资深团队现在更喜欢那些明确甚至枯燥的系统，而不是那些感觉神奇但不透明的系统。

框架是赋能者，而非答案

这种转变在整个生态系统中都可见。Angular 就是一个很好的例子。它曾被视为重型客户端开发的原型，但现在已稳步拥抱服务端渲染、细粒度水合。重要的是，它并没有规定单一的使用方式。

这种模式在其他地方也在重演。现代框架不再试图赢得意识形态战争。它们提供的是旋钮和拨盘，用来控制工作何时发生、状态驻留何处以及渲染如何随时间展开。

竞争不再关乎纯粹性。而是关乎现实约束下的灵活性。纯粹的架构在新建项目中看起来很棒，但它们的衰老过程往往不够优雅。

随着需求演变（它们总是会的），严格的模型会积累例外。最初的一套干净规则变成了一堆限制条件。早期就承认复杂性的架构往往更具弹性。清晰的界限使得在不 destabilizing 其他部分的情况下演进系统的某一部分成为可能。

2026 年的严谨性不在于强制执行同一性，而在于强制执行清晰度：知道代码在哪里运行、为什么在那里运行，以及故障如何传播。

小结

构建 Web 的单一“正确”方法的理念终于失去了其控制力。这是一件好事。

服务端渲染和客户端应用从来都不是敌人。它们是在不同时间解决不同问题的工具。Web 已经成熟到足以承认，大多数架构问题都没有通用的答案。

今天最成功的团队并不是在追逐趋势。他们了解自己的约束，尊重自己的性能预算，并将渲染视为一个光谱，而不是一个开关。Web 的成长不是因为选边站队，而是因为拥抱了细微差别。而那些能够持久的架构，正是那些同样做到这一点的架构。