在现代前端架构中，CSR（Client Side Rendering）与 SSR（Server Side Rendering）不仅是基础概念，更直接影响首屏性能、SEO 表现、转化率与系统成本。
这篇文章在基础原理之上，重点补充：
- 可视化流程图（帮助面试表达）
- SSR 性能优化（缓存 / CDN / 边缘渲染）
- 真实项目选型（结合 AI / 面试系统）
- 工程化方案（Next.js / SSG / Streaming）
一、CSR 渲染流程
1.1 流程图
关键结论：
CSR 是一个“串行阻塞流程” （HTML → JS → 数据 → 渲染）
1.2 为什么首屏慢（本质原因）
不是因为“用 React 慢”，而是：
- JS 体积大（bundle）
- JS 执行阻塞主线程
- 数据请求在 JS 之后才发生
面试一句话：
CSR 首屏慢的本质是“资源加载 + JS 执行 + 数据请求”的串行依赖。
1.3 CSR 优化体系
1）代码分割
const Page = React.lazy(() => import('./Page'))
2）骨架屏
用户“感觉快”，不等于真的快。
3）预加载策略
- preload（当前关键资源）
- prefetch（未来资源）
4）数据层优化
- SWR / React Query（缓存 + 预取）
二、SSR 渲染流程
2.1 流程图
2.2 Hydration 本质
React 在客户端“再执行一遍”，把事件绑定到已有 DOM 上。
不是重新渲染，而是：
- 复用 DOM
- 绑定事件
- 建立状态
关键词： “静态 → 可交互”
三、CSR vs SSR 核心差异（升维总结）
| 维度 | CSR | SSR |
|---|---|---|
| 渲染位置 | 浏览器 | 服务器 |
| 首屏 | 慢 | 快 |
| SEO | 差 | 好 |
| TTFB | 快 | 相对慢 |
| FCP | 慢 | 快 |
| 复杂度 | 低 | 高 |
面试加分点：
SSR 提升的是 FCP（首次内容绘制），但可能牺牲 TTFB（首字节时间）。
四、SSR 性能优化
很多人只会说“SSR 快”，但面试官更想听：
如何让 SSR 更快？
4.1 页面缓存
CDN 缓存
- HTML 直接缓存
- 命中后不走服务器
极大降低服务器压力
服务端缓存
if (cache.has(url)) return cache.get(url)
4.2 边缘渲染
- 在离用户最近的节点执行 SSR
- 降低网络延迟
Vercel / Cloudflare Workers
4.3 Streaming SSR
renderToPipeableStream()
特点：
- 边渲染边返回
- 不用等完整 HTML
首屏更快
4.4 数据并行请求
避免：
await A
await B
改为：
await Promise.all([A, B])
五、业务选型
5.1 CSR 适合什么？
ToB 系统
- 不依赖 SEO
- 强交互
- 权限复杂
典型：管理后台
高交互应用
- Canvas
- 工作流
- 可视化
CSR 更灵活
5.2 SSR 适合什么？
ToC 内容产品
- 博客
- 电商
- 资讯
SEO + 首屏体验
转化率敏感页面
- 落地页
- 活动页
首屏速度 = 收入
5.3 一个现实认知
移动时代很多流量来自 App / 推荐流，SEO 权重下降，但“首屏体验”仍然关键。
六、现代最佳实践（一定要提）
6.1 Next.js（主流方案）
- SSR
- SSG
- ISR（增量静态生成）
6.2 SSG（静态生成）
- 构建时生成 HTML
- CDN 分发
性能极致
6.3 ISR（增量更新）
- 页面可定期重新生成
兼顾性能与实时性
七、总结
CSR 解决的是“交互体验”，SSR 解决的是“首屏与可见性”。
更高级的理解是：
前端渲染本质是在做“时间换空间 or 空间换时间”的权衡。
- CSR：把压力放到客户端（时间换成本）
- SSR：把压力放到服务器（成本换体验）
