极客教程

Appearance

服务端渲染时代：把"拼页面"搬上服务器 ​

最后更新：2026-08-19

本主题要回答的问题 ​

  1. CGI 到 PHP/JSP/ASP 再到模板引擎，服务端动态化经历了怎样的技术换代？
  2. 为什么"每个请求重新拼一次 HTML"会成为性能瓶颈？
  3. 服务端渲染时代的核心矛盾是什么？它如何被 AJAX 时代接管？

一、三代方案：从"进程"到"解释器常驻"到"模板分离" ​

1. CGI（1993）：一次请求 = 一个进程 ​

CGI（Common Gateway Interface）是第一个动态网页方案：Web 服务器收到请求后，fork 一个外部程序（Perl/C 脚本），程序读取输入、拼出 HTML、输出后进程退出。

plantuml diagram

致命缺陷：每次请求都 fork 一个新进程，进程创建 + 解释器初始化开销巨大。高并发下服务器直接被"进程风暴"压垮——这催生了"解释器常驻"方案。

2. PHP / JSP / ASP（1995~1997）：解释器驻留 Web 服务器进程 ​

方案语言代表产品特点
PHPPHPWordPress、Discuz脚本与 HTML 混写，LAMP 时代主角
ASPVBScriptWindows 时代微软系，绑定 IIS
JSPJavaServlet/JSP编译成字节码，企业级 Java EE

核心变化：解释器不再每请求启动一次（PHP 以模块形式驻留 Apache，Java 用常驻 Servlet 容器），吞吐量比 CGI 高一到两个数量级。但此时页面代码是"HTML 里嵌逻辑"：

php
<?php
// 传统 PHP：HTML 与逻辑混写
$rows = $db->query("SELECT * FROM posts");
foreach ($rows as $row) {
    echo "<h2>" . $row['title'] . "</h2>";
}
?>

3. 模板引擎（2000s）：逻辑与展示分离 ​

"代码里拼 HTML"让前端改版必须动后端代码。模板引擎（Smarty、Velocity、Django Template、Jinja2）把数据与视图分离：

html
<!-- 模板：只描述"长什么样"，数据由控制器注入 -->
{% for post in posts %}
  <h2>{{ post.title }}</h2>
  <p>{{ post.summary }}</p>
{% endfor %}
对比项HTML 嵌逻辑（PHP 混写）模板引擎
前后端分工前端要懂后端代码模板语言简单，前端可独立维护
复用性逻辑复制粘贴组件/宏/继承机制
可测试性难模板可单测、可预览

二、时代成就：动态内容 + 数据库 + 用户体系 ​

服务端渲染时代奠定了现代 Web 的三件套：

能力实现方式代表
动态内容请求时查询数据库拼 HTML新闻、论坛、博客
用户体系Cookie/Session 维护登录态邮箱、电商
业务逻辑服务端代码集中管理订单、支付

三、核心矛盾：每次整页刷新 + 服务器压力 ​

服务端渲染的代价在"交互密集"的场景下暴露：

  1. 整页刷新：点一个"赞"、翻一页，都要重新下载整个页面（HTML+CSS+JS+图片全量）；
  2. 服务器重复劳动：同一页面被 1000 人访问，就拼 1000 次 HTML（模板渲染是 CPU 活）；
  3. 状态割裂：页面刷新后所有 JS 内存状态丢失，表单内容要回传重填。
plantuml diagram

转折点：2005 年 Gmail、Google Maps 发布——它们证明"不刷新页面也能更新内容"，AJAX 时代开始接管交互密集场景。服务端渲染并没有消失，而是退居"首屏/SEO"阵地，直到时代五以 SSR 形式回归。

一句话总结 ​

服务端渲染时代解决了"内容动态化"，代价是"每次交互都整页刷新、服务器重复拼装"——当交互成为主要矛盾时，它必然被 AJAX/SPA 取代；但"服务端先出 HTML"的思路（SEO、首屏快）从未过时，三十年后以 SSR 的形式原样回归。