1. SSR
全称 Server-Side Rendering，服务端渲染 —— 现做
举例：顾客想吃碗河南烩面，厨师收到通知现做（后端服务器收到请求后，动态生成页面想要的数据），厨师做好之后把烩面端给客人（返回完整的 HTML 页面）。
技术本质： 用户每次请求时，服务器实时组装数据和模板生成 HTML 再返回给浏览器。
优缺点对比
- 🚀 优点：
- 首屏加载快（直接返回渲染好的 HTML）
- 完美支持动态数据（如用户仪表盘）
- SEO 友好（搜索引擎直接抓取完整内容）
- ⚠️ 缺点：
- 服务器压力大（每次请求需重新渲染）
- 开发复杂（需处理服务端/客户端环境差异）
应用场景
✅ 电商商品页（实时价格）
✅ 社交平台（个性化内容）
✅ 新闻网站（即时更新）
代码示例（React SSR）
// server.js（服务端）
import express from 'express';
import React from 'react';
import { renderToString } from 'react-dom/server';
const app = express();
// 实时获取数据（模拟API）
app.get('/', (req, res) => {
const user = { name: "知否技术" };
// 渲染组件为HTML字符串
const html = renderToString(<h1>Hello, {user.name}!</h1>);
// 返回完整HTML
res.send(`
<html>
<body>${html}</body>
</html>
`);
});
app.listen(3000);
2. SSG
全称 Static Site Generation，静态站点生成 —— 预制菜
举例：厨房提前做好所有菜品（网页在构建时就生成静态 HTML），客人来了直接上菜（浏览器直接加载静态文件）。
技术本质：项目构建时一次性生成所有页面 HTML，部署后直接返回静态文件
优劣对比
- 🚀 优点：
- 加载速度极快（CDN 毫秒级响应）
- 安全性高（无服务端动态逻辑）
- 成本低
- ⚠️ 缺点：
- 数据更新需重新构建
- 无法处理用户个性化内容
应用场景
✅ 技术博客（Markdown 内容，比如上篇文章讲的 VitePress 就是产出 SSG 的应用框架）
✅ 企业官网（固定信息）
✅ 产品文档（内容稳定）
代码示例（Next.js SSG）
// 模拟从数据库获取数据（在实际项目中，可以是 API 请求）
const getStaticProps = async () => {
// 这里模拟从数据库获取数据，实际项目可以替换成真实的 API 请求
const data = {
blogPosts: [
{ id: 1, title: '知否君的第一篇博客', content: '博客内容...' },
{ id: 2, title: '知否君前端技术的建议', content: '学习心得...' }
]
};
return {
props: { data }, // 将数据传递给页面组件
};
};
// 页面组件
const SSGPage = ({ data }) => {
return (
<div>
<h1>博客列表（SSG）</h1>
<ul>
{data.blogPosts.map(post => (
<li key={post.id}>
<h2>{post.title}</h2>
<p>{post.content}</p>
</li>
))}
</ul>
</div>
);
};
export { getStaticProps };
export default SSGPage;
🔍 3、SSR vs SSG 核心对比
| 维度 | SSR | SSG |
|---|---|---|
| 渲染时机 | 用户请求时动态生成 | 项目构建时预生成 |
| 首屏速度 | 快（依赖服务器性能） | ⚡ 极快（CDN 直接返回） |
| 动态数据 | ✅ 实时支持（如股票价格） | ❌ 仅支持构建时数据 |
| 服务器压力 | 高（每次请求需渲染） | 低（仅返回静态文件） |
| 典型场景 | 电商/社交App/后台管理系统 | 博客/官网/文档站 |
4、选择指南
💎 总结
- SSR = 动态内容优先（用户相关、实时更新）
- SSG = 静态内容王者（速度碾压、成本低廉）
应用场景：
- 公司官网首页用 SSG（极速打开）
- 用户订单数据用 SSR（实时数据）
- 博客文章页用 SSG + SSR（定时更新评论）
