前端渲染策略选错，后面会在性能、SEO 和维护成本上反复付学费。
很多团队的问题不是不会写页面，而是没有把“页面类型”与“渲染方式”对应起来，导致一套方案硬套全部页面。
先判断页面类型，再选渲染方案
我一般先把页面分成三类：
- 强内容页：文档、博客、落地页
- 强交互页：控制台、后台、编辑器
- 混合页：首屏需要 SEO，后续强交互
对应策略通常是：
- 强内容页优先
SSG或SSR - 强交互页优先
CSR - 混合页采用“首屏服务端 + 客户端增量交互”
这个映射比讨论框架更重要。
真正影响体验的是首屏与可交互时间
用户感知里最明显的两个指标是：
- 首屏是否尽快可见
- 页面多久可以真正操作
所以渲染策略不该只看 TTFB，也要看 hydration 成本、关键资源体积和请求瀑布。
如果一个 SSR 页面首屏快，但 hydration 卡 2 秒，用户体验依然差。
团队协作层面的取舍
渲染策略还会影响工程协作：
SSR对后端边界、缓存策略、错误监控要求更高SSG发布链路更关键，需要把内容与构建流程打通CSR前端自治更强，但 SEO 和首屏体验需要额外补偿
当团队规模上来后，这些取舍往往比“理论性能差异”更决定项目成败。
一个实用的落地原则
先用最小复杂度达到业务目标，再局部升级。
例如：
- 先用 SSG 把内容页稳定上线
- 对关键入口页按需引入 SSR
- 对复杂交互区保持 CSR
这种“分区治理”比全站一次性重构要稳得多。
小结
渲染策略不是技术偏好问题，而是业务目标与工程成本的平衡。
把页面类型划分清楚，80% 的决策会自然变简单。