Angular SSR 中关于静态生成(SSG)与动态渲染(SSR)的重要细节

在 Angular 的服务器端渲染(SSR)实现中，开发者需要特别注意一个关键行为差异：默认情况下，所有路由都会被当作静态站点生成(SSG)处理，而不是预期的服务器端渲染(SSR)。这一行为差异会导致一些常见问题，特别是当开发者尝试访问请求上下文时。

核心问题表现

当开发者使用 Angular 的 SSR 功能时，可能会遇到以下典型问题：

1. REQUEST 和 REQUEST_CONTEXT 注入令牌始终返回 null
2. PlatformLocation 无法正确获取查询参数
3. 页面始终带有 ng-server-context="ssg" 标记

这些问题都源于同一个根本原因：应用在没有明确配置的情况下，默认使用了静态生成模式。

技术原理分析

Angular 的 SSR 系统实际上包含两种不同的渲染模式：

1. 静态站点生成(SSG)：在构建时预渲染页面，适合内容不频繁变化的页面
2. 服务器端渲染(SSR)：在每次请求时动态渲染页面，适合个性化或动态内容

默认情况下，Angular 会优先使用 SSG 模式，因为这种模式性能更好。只有当开发者显式配置了服务器路由(ServerRoutes)时，系统才会切换到真正的 SSR 模式。

解决方案

要强制应用使用真正的 SSR 模式，开发者需要在 app.config.server.ts 文件中进行明确配置：

import { provideServerRouting, RenderMode } from '@angular/ssr';

export const serverConfig: ApplicationConfig = {
  providers: [
    provideServerRouting([
      {
        path: '**',  // 匹配所有路由
        renderMode: RenderMode.Server,  // 强制使用服务器渲染
      },
    ]),
  ],
};

这种配置确保了所有路由都会在每次请求时动态渲染，而不是使用预先生成的静态内容。

最佳实践建议

1. 明确渲染模式选择：根据页面特性决定使用 SSG 还是 SSR
2. 混合使用策略：可以对不同路由配置不同渲染模式
3. 性能考量：静态内容优先使用 SSG，动态内容使用 SSR
4. 开发环境验证：始终检查 ng-server-context 属性确认实际渲染模式

深入理解

理解这一行为差异的关键在于认识到 Angular SSR 系统的设计哲学：默认选择最高效的渲染方式。这种设计虽然提高了性能，但也带来了开发体验上的一些困惑。开发者需要主动声明哪些路由需要真正的服务器端处理能力，而不是假设所有路由都会在服务器端动态渲染。

对于需要访问请求上下文的场景，如国际化、个性化内容或基于请求头的适配，必须确保相关路由配置了 RenderMode.Server。只有这样，注入的 REQUEST 和 REQUEST_CONTEXT 才会包含有效的请求信息。