狠狠吐槽一下SSR/Next.js（五）：SSR 是一种技术上的后退

开篇技术演进的回旋与思考让我们回顾一下Web渲染技术的发展历程。Web 1.0 时代1990s-2000s所有页面都在服务器上渲染好输出完整的HTML。每次交互都需要刷新整个页面。这种模式后来被归纳为——“服务端渲染”。Web 2.0 时代2010s前后随着AJAX的普及和前端框架的崛起渲染逻辑逐渐迁移到浏览器中实现了无刷新的页面更新。这标志着前端的独立——前端终于从后端模板引擎中解放出来。这种模式被称为“客户端渲染”CSR单页应用SPA成为主流。Web 3.0 时代2020s以Next.js为代表的框架倡导回归服务端渲染并称之为SSR服务端渲染宣称这是未来的趋势。这里引发了一个值得深思的问题我们用十年时间将渲染从服务器迁移到客户端如今又倡导回归服务器这究竟是技术的螺旋式上升还是一种简单的轮回从架构视角看SSR引入了一个新的环节水合Hydration。即服务器生成静态HTML“骨架”浏览器再加载JavaScript为其注入交互能力“赋予生命”。这一过程增加了架构的复杂性。一、SSR对“关注点分离”原则的挑战软件工程的一个重要基石是关注点分离Separation of Concerns。它倡导不同层级的代码应各司其职。在经典的CSR架构中前后端边界清晰后端提供数据接口如RESTful API或GraphQL。前端消费接口数据负责UI渲染与交互。接口契约成为双方协作的清晰边界。SSR模式在一定程度上模糊了这一边界。前端开发者可能需要在组件中编写服务器端数据获取逻辑如getServerSideProps而后端逻辑也可能与前端渲染结构产生耦合。这并非否定全栈开发的价值而是指出当渲染环境与数据环境混杂在同一代码路径中时维护和理解成本会显著上升。它让人回想起早期JSP/PHP时代前后端代码混杂的状态而清晰的分离正是我们从那个时代走出来的原因。二、CSR与SSR的性能模型辨析常听到对CSR的批评是“首屏加载慢白屏时间长”。我们需要更细致地分析两者的性能模型。CSR的性能模型是稳定且可预测的用户访问 → 下载HTML骨架 → 下载JS/CSS资源 → 执行JS → 请求数据 → 渲染页面主要耗时在于资源加载与解析这部分可通过CDN、缓存、代码分割大幅优化。一旦核心资源被缓存后续访问速度极快。服务器仅需提供静态资源和API压力小架构简单。SSR的性能模型则更为复杂用户访问 → 请求到达服务器 → 服务器执行渲染逻辑可能包含数据查询→ 生成HTML → 返回 → 浏览器下载JS → 水合 → 页面可交互SSR确实能更快地显示初始内容但可交互时间TTI可能并未改善甚至更差。用户看到了内容却无法立即操作需要等待水合完成。此外还有一个常被忽视的点延迟。CSR的静态资源可通过全球CDN分发从离用户最近的节点获取。SSR的HTML往往由源站服务器或区域边缘函数动态生成网络延迟可能更高。将渲染从距离用户50ms的CDN转移到200ms外的源站真的是一种全面的性能提升吗三、架构范式边缘友好与中心依赖在边缘计算兴起的今天架构的“边缘友好”特性愈发重要。CSR本质上是边缘友好的渲染发生在用户的浏览器中计算负载完全分散具备近乎无限的水平扩展能力。SSR则更倾向于中心化或区域中心化每个页面请求都可能触发一次服务器端的渲染计算。这带来了新的挑战流量激增时渲染服务可能成为瓶颈。下游API延迟会直接拖累整个页面响应。服务可用性直接决定了页面可用性。为了追求“首屏内容更快”我们是否将应用的整体弹性与一个中心化的渲染服务绑定了这值得架构师权衡。四、SSR的核心驱动力SEO与内容可发现性客观地说SSR的一个重要驱动力是解决搜索引擎优化SEO和社交内容抓取的问题。许多搜索引擎爬虫和历史悠久的社交平台爬虫对JavaScript的执行支持有限或存在延迟。对于重度依赖客户端渲染的SPA这可能导致内容无法被正确索引。因此SSR常常是为了适应外部生态爬虫而采取的技术妥协而非纯粹出于技术优越性。这引出一个思考我们是因为SSR本身更优秀而选择它还是为了迁就尚未完全现代化的网络爬虫当爬虫技术全面进化后SSR的这部分价值是否会衰减五、AI时代的新审视SSR的“可理解性”挑战AI正在成为软件开发的重要参与者。评估一个架构时我们多了一个新维度AI能否轻松理解、生成和维护该架构的代码CSR的架构是线性的、环境单一的数据API → 视图组件 → 交互事件AI很容易建立这样的心智模型代码在浏览器环境运行数据来自网络请求。SSR的架构则涉及多环境、多阶段构建时静态生成←→ 请求时服务端渲染←→ 客户端水合与交互←→ 重新验证增量更新同一份组件代码需要根据环境服务器/客户端和阶段渲染/水合/交互表现不同的行为。这形成了一个复杂的有状态图。这种复杂性不仅增加了开发者的认知负荷同样也提高了AI工具准确理解和操作代码的难度。在自动化代码生成、重构、分析和测试场景下环境混杂的代码更容易导致工具出错或效率降低。六、另一种未来拥抱清晰回归纯粹那么在AI时代我们应该追求怎样的前端架构我的建议是追求环境清晰、职责分明的架构。采用清晰的CSR架构使用Vite React/Vue等现代工具链构建应用。保持渲染逻辑在客户端。利用边缘缓存与预取通过CDN、HTTP/2 Server Push、资源预加载等技术最大化利用边缘网络优化首屏体验。使用静态站点生成SSG对于内容相对固定的页面在构建时生成HTML完美解决SEO问题无需动态SSR。在客户端进行数据获取使用fetch、TanStack Query等工具逻辑清晰易于缓存和状态管理。保持后端服务的独立性业务逻辑、数据持久化、复杂计算应放在独立的后端服务中通过明确的API契约与前端通信。这样的架构不追逐“全栈在同一项目中”的潮流但它简单、可靠、易于维护并且对人和AI都更加友好。结语在轮回中寻找前进的方向技术发展常呈现钟摆现象。我们从服务端渲染Web 1.0摆向客户端渲染Web 2.0如今又在探讨服务端渲染的回归SSR。SSR作为一种技术方案在特定场景如强SEO需求、初始内容极度敏感下有其价值。但它所引入的复杂性——环境混合、水合、更复杂的性能分析、对AI工具的不友好——也是实实在在的成本。技术的选择不应是非此即彼的信仰之争而应是基于具体场景的理性权衡。在AI日益融入开发流程的今天架构的“可理解性”和“可维护性”或许应被赋予更高的权重。也许真正的进步不在于在“服务器渲染”和“客户端渲染”之间做出绝对选择而在于构建边界清晰、职责明确、工具链友好的系统让浏览器做它擅长的事让服务器做它擅长的事让开发者和AI能清晰地理解每一行代码的归宿。