在现代前端开发的江湖里咱们每天dou在跟各种框架和概念打交道。但说到底，无论技术怎么迭代，核心问题始终绕不开一个：这网页，到底是谁给画出来的？ 是用户的浏览器辛辛苦苦算出来的，还是远端的服务器早就准备好直接甩过来的？

这不仅仅是个技术选型问题，geng是关乎用户体验、SEO排名甚至团队KPI的生死大事。今天咱们不整那些虚头巴脑的理论，直接扒开裤腿kankan里子，聊聊CSR、SSR、同构渲染的爱恨情仇，Zui后还要硬核一把，从零手写一个基于 Vite + Express + React 的 SSR 服务，让你彻底搞懂这背后的黑魔法。

前端渲染的“前世今生”：从CSR到SSR的纠葛

想当年，jQuery还没退位，PHP和JSP还在横行的时候，网页其实大部分dou是SSR。那时候简单啊，浏览器发个请求，服务器查数据、拼HTML，一股脑丢给浏览器，用户kan到的就是完整的页面。虽然交互差点意思，但胜在首屏快，爬虫也爱kan。

后来React、Vue这些现代框架横空出世，SPA成了主流。这时候，CSR站上了C位。它的逻辑是：服务器你别管了就给我发个空壳HTML，剩下的JS、路由、数据获取，全dou在浏览器里搞定。

CSR：体验虽好，但“首屏”hen痛

咱们现在的后台管理系统、SaaS工具，大部分dou是CSR。为啥？开发体验好啊，前后端分离，前端想怎么折腾怎么折腾，页面切换如丝般顺滑。

但是这玩意儿有个致命的痛点：白屏。用户网速稍微差点，或者设备差点，打开页面就是一片白，得等那个巨大的JS包下载完、解析完、执行完，页面才出来。geng别提SEO了爬虫爬过来一kan，好家伙，除了个`

`，啥也没有，这还怎么排名？

SSR：为了SEO和首屏，我们回去了

为了解决CSR的这些毛病，业界把目光重新投向了服务器。既然Node.jsNeng跑JS，那咱们Neng不Neng在服务器端就把React/Vue组件跑一遍，生成完整的HTML再发给浏览器？

这就是SSR。它的好处显而易见：首屏直接出内容，不用等JS加载；爬虫也Neng读到内容，SEO满分。但代价呢？服务器压力大了开发复杂度也高了毕竟Node环境里没有`window`和`document`对象，写代码得小心翼翼。

深入剖析：到底什么是同构渲染？

非黑即白的时代早就过去了。小孩子才Zuo选择，成年人的世界是“我全dou要”。为了结合CSR的丝滑交互和SSR的极速首屏，同构渲染应运而生。

同构的口诀其实hen简单：首次访问走SSR，后续交互走CSR。

具体来说就是一套代码，两端运行。第一次请求，服务器把组件渲染成HTML字符串发出去；浏览器拿到HTML后立马展示给用户。同时浏览器也会加载那个JS文件，等JS跑起来后它会“接管”页面把那个静态的HTML“激活”，绑定上事件监听器。之后用户再点按钮、跳路由，就全是CSR的逻辑了不再麻烦服务器。

Next.js、Nuxt.js这些框架，本质上就是把这套流程封装得特别好，让你感觉不到SSR和CSR的切换。但作为资深工程师，咱们不Neng只知其然不知其所以然。

拒绝黑盒：手把手教你用Vite + Express打造React SSR

说了这么多概念，不如动手写一遍。咱们抛开Next.js的封装，用Zui原生的Vite、Express和React，从零搭一个SSR服务。这不仅Neng让你理解原理，以后遇到什么奇奇怪怪的SSR报错，你也Neng一眼kan穿。

咱们这个架构里Express是Web服务器，负责接请求；Vite是编译器，负责把JSX转成JS；React是UI库。咱们要Zuo的，就是让它们三个配合默契。

第一步：准备一个“空壳”HTML模板

你得有个HTML文件。注意，这不是普通的HTML，它得有个占位符，等着服务器把渲染好的内容塞进去。

kan到那个``了吗？这就是咱们要动手脚的地方。另外`entry-client.jsx`是客户端的入口，稍后咱们会写它。

第二步：编写React组件，别忘了加点“料”

咱们写个极简的组件。为了验证SSR后的“水合”是否成功，咱们加个点击事件。Ru果只是单纯的HTML替换，点击是不会弹窗的；只有水合成功，JS逻辑接管了DOM，点击才会有反应。

import React from 'react';
export default function App {
    return (
         alert}>
            Hello Vite SSR
        
    );
}

第三步：双端入口设计——服务端与客户端的分工

同构应用得有两个入口，一个给服务器跑，一个给浏览器跑。

服务端入口： 它的职责是把React组件变成字符串。注意，这里不Neng操作DOM，也不Neng执行`useEffect`这种生命周期。

import React from 'react';
// react-dom/server 提供将组件渲染为 HTML 字符串的Neng力
import { renderToString } from 'react-dom/server';
import App from './App';
export function render {
    console.log;
    return renderToString;
}

客户端入口： 它的职责是“水合”。它要把服务器生成的静态HTML“复活”，把事件监听器粘上去。

import React from 'react';
import { hydrateRoot } from 'react-dom/client';
import App from './App';
console.log;
// 水合渲染：让服务器端的 HTML 字符串变成可交互的页面
// React 在前端再执行一次与现有 DOM 对比，注入事件和逻辑
hydrateRoot, );

第四步：核心调度——Express与Vite的完美共舞

这是Zui精彩的部分。咱们要写一个`server.js`，让Express和Vite协同工作。

这里有个坑：Node.js原生是不认识`.jsx`语法的。以前咱们用Webpack，配置起来Neng把人逼疯。现在有了Vite，事情简单多了。咱们Ke以用Vite提供的API，把它作为一个中间件塞进Express里让它帮咱们实时编译代码。

import fs from 'fs';
import path from 'path';
import express from 'express';
import { createServer as createViteServer } from 'vite';
// 获取当前目录的绝对路径
const __dirname = path.resolve;
const app = express;
async function start {
    console.log;
    // 1. 以中间件模式创建 Vite 服务器
    const vite = await createViteServer({
        server: { 
            middlewareMode: true // 关键：告诉 Vite 不要自己启动 HTTP 服务
        },
        appType: 'custom' // 告诉 Vite 页面 HTML 的渲染由 Express 接管
    });
    // 2. 将 Vite 作为中间件注入到 Express
    // 这样它就Neng处理静态资源、热geng新逻辑了
    app.use;
    // 3. 拦截所有请求，手写 SSR 逻辑
    app.use => {
        try {
            // A. 同步读取原始的 index.html 模板
            let template = fs.readFileSync(
                path.resolve,
                'utf-8'
            );
            // B. 让 Vite 接管 HTML 转换
            // 这一步至关重要，它会注入 Vite 的 HMR 热geng新脚本
            template = await vite.transformIndexHtml;
            // C. 加载服务器端入口文件
            // vite.ssrLoadModule 突破 Node 限制，动态编译 jsx 并返回模块对象
            const { render } = await vite.ssrLoadModule;
            // D. 在服务端执行 render，将 React 组件渲染成完整的 HTML 字符串
            const html = await render;
            // E. 将渲染出的 HTML 字符串替换到模板的占位符中
            template = template.replace;
            // F. 将组装好的完整 HTML 返回给浏览器
            res.status.set.end;
        } catch  {
            // 捕获编译错误，通过 Vite 修复堆栈追踪
            vite.ssrFixStacktrace;
            res.status.end;
        }
    });
}
app.listen => {
    console.log;
});
start;

kan到这段代码，是不是觉得豁然开朗？Vite在这里就像个“包工头”，它利用`ssrLoadModule`方法，在Node环境里把JSX实时编译成可执行的代码，然后咱们调用`render`方法拿到HTML字符串，Zui后塞进模板里发出去。整个过程一气呵成。

你到底该选哪条路？

通过这一番折腾，咱们算是把前端渲染的闭环走通了。从CSR的简单粗暴，到SSR的严谨高效，再到同构的取长补短，Zui后到底层原理的亲手实现。

那么回到Zui初的问题：你geng倾向于哪种？

其实这根本就没有标准答案。Ru果你的项目是给内部人员用的后台管理系统，别犹豫，老老实实搞CSR，开发效率Zui高，维护成本Zui低。但Ru果你Zuo的是C端业务，比如电商首页、新闻门户，对首屏速度和SEO有苛刻要求，那SSR或者同构渲染绝对是你的不二之选。

虽然Next.jsYi经hen强大了但了解如何手写SSR，Neng让你对数据流向、编译过程、水合机制有geng深刻的理解。这不仅仅是炫技，geng是为了知其然geng要知其所以然才是咱们资深工程师的立身之本啊。

---