CSR、SSR、SSG 各适合什么
先理解原理和示例，再练习完整口述与追问。
回答要点
CSR 主要在客户端生成界面；SSR 按请求在服务端生成 HTML；SSG 在构建等阶段预生成。比较首屏、SEO、内容实时性、服务成本和缓存。SSR 仍需要客户端 JS 水合，不会自动消除慢接口和重脚本。
原理拆解
CSR 先下发页面外壳和脚本，再在浏览器获取数据渲染；SSR 在请求期间生成包含内容的 HTML；SSG 在构建或预生成阶段生成页面。选择取决于内容变化频率、是否个性化、首屏、抓取与服务器成本。SSR 与 SSG 仍可能在客户端水合以接入交互，因此生成 HTML 与后续是否需要 JS 是两条维度。
示例与推演
企业内部高度交互后台可优先 CSR；新闻详情可用 SSG 加适当更新机制；个性化且需快速内容首屏的页面可考虑 SSR。先输出 HTML 可以改善内容到达，但慢接口也可能拖长 TTFB；页面最终可交互还受脚本大小与水合成本影响。
易错点
不要断言 SSR 一定更快或所有爬虫不执行 JS。个性化 SSR 缓存必须隔离用户，SSG 的构建时数据也要有更新与过期策略。
参考回答可直接练习口述
CSR 主要由浏览器加载 JS 后生成页面，适合大量登录后的交互应用；SSR 按请求先生成 HTML，便于首屏内容和可索引性，但增加服务端成本，并需要客户端水合；SSG 预生成静态页面，适合内容可提前构建且允许一定更新延迟的场景。选择时看实时性、SEO、访问规模、部署和缓存。SSR 不会自动消除慢接口、JS 体积或客户端重计算。