Next.js 和 Nuxt 这类 SSR 框架解决了什么问题？

简化版

Next.js 和 Nuxt 提供了 SSR/SSG、路由、数据获取、构建优化、代码分割、图片优化、部署适配等能力。它们让团队不用从零搭建同构渲染基础设施，而是基于约定完成页面开发和性能优化。

这类框架通常解决：

Next.js 主要服务 React 生态，Nuxt 主要服务 Vue 生态。选型通常看团队技术栈、生态、业务复杂度和部署环境。

手写 SSR 不只是调用一次 renderToString。还要处理路由匹配、数据获取、资源注入、错误页面、缓存、水合、代码分割、开发体验和部署。

SSR 框架把这些通用复杂度封装起来，让开发者关注页面和业务。

现代 SSR 框架通常不只支持 SSR，还支持 SSG、增量静态生成、客户端渲染混合等模式。

不同页面可以选择不同渲染策略。例如营销页用 SSG，用户中心用 CSR，商品详情用 SSR 或 ISR。

这种按页面选择模式的能力非常重要。

框架还会提供自动代码分割、资源预加载、图片优化、meta 管理、错误边界、开发热更新等能力。

这些能力不是语法糖，而是大型项目稳定落地 SSR 的基础设施。它们共享同一份路由和构建信息，能避免手工拼装时服务端资源清单与客户端 bundle 版本错位。

面试官可能问：“用了 Next/Nuxt 就不用理解 SSR 原理了吗？”

当然不是。框架能降低使用门槛，但遇到水合不一致、缓存串用户、首屏慢、服务端报错时，仍然需要理解 SSR 原理才能排查。

工程选型时要考虑部署平台。部分能力依赖 Node 服务、边缘函数或特定托管平台。

一次请求不只是执行组件：

路由匹配 → 中间件/鉴权 → 数据依赖 → 服务端渲染
→ 资源清单与初始数据注入 → 缓存头 → 客户端水合/导航

一个 20 人团队若各自实现缓存 key、错误页和 head 注入，很快会出现不一致。框架通过约定减少选择面，但约定也意味着升级和部署平台会影响应用架构。

学框架要沿请求流水线理解：每个 API 在服务端、构建时还是浏览器执行，数据在哪层缓存，失效由谁负责。

Next.js 面向 React 生态，Nuxt 面向 Vue 生态；不应只比较 API 名字。评估团队组件资产、第三方库 SSR 兼容、运行时要求、缓存能力、部署锁定、升级节奏和可观测性。

同一项目可以把 1000 篇文档 SSG，把商品详情 ISR/SSR，把登录后控制台 CSR。渲染模式按页面数据实时性、SEO、个性化和成本选择，而不是“用了 SSR 框架就全站每请求 SSR”。

建立最小样板验证真实约束：冷启动 TTFB、缓存命中、动态路由数量、水合 JS、错误日志、流式响应和目标平台回滚。框架基准 demo 很快，不代表带上实际组件库、鉴权和数据层仍然快。

升级时重点回归缓存和运行时语义。现代框架迭代快，同名能力在不同主版本可能行为不同；回答具体 API 时应先说明版本，长期教学则聚焦稳定的渲染原理。

团队还要建立“框架默认值清单”：哪些路由静态化、哪些响应缓存、哪些模块进入客户端。默认行为在升级后变化时，清单与回归测试能及时暴露差异。