Angular SSR 核心依赖解析：@angular/platform-server 与 @angular/ssr 职责辨析

你可以把 @angular/platform-server 理解为：能跑，但不一定好用。它负责让引擎在服务器跑起来，并把组件树变成 HTML，却不负责把你的工程结构、路由渲染策略、开发与构建链路一并'打包成一套顺手方案'。

@angular/ssr：工程化与策略封装

@angular/ssr 的角色更偏向'把 SSR 做成可配置、可落地、可维护的一整套方案'。

官方指南明确写到：你可以用 ng add @angular/ssr 给既有项目添加服务端与混合渲染能力，并且默认会做 prerender 与生成 server 文件等工作。

更关键的是，它把'按路由选择渲染模式'这件事产品化了：通过 ServerRoute 与 RenderMode，你能非常清晰地声明哪些路由走 CSR，哪些路由走 SSG，哪些路由走 SSR。官方示例大概长这样：

// app.routes.server.ts
import { RenderMode, type ServerRoute } from '@angular/ssr';

export const serverRoutes: ServerRoute[] = [
  { path: '', renderMode: RenderMode.Client },
  { path: 'about', renderMode: RenderMode.Prerender },
  { path: 'profile', renderMode: RenderMode.Server },
  { path: '**', renderMode: RenderMode.Server },
];

然后把它挂到服务端配置里：

// app.config.server.ts
import { provideServerRendering, withRoutes } from '@angular/ssr';
import { serverRoutes } from './app.routes.server';

export const serverConfig = {
  providers: [
    provideServerRendering(withRoutes(serverRoutes)),
  ],
};

这些 API 的文档也明确了语义：

• provideServerRendering() 用来配置 Angular 应用的服务端渲染能力，并可组合 withRoutes、withAppShell 等特性。
• withRoutes() 注册服务端路由配置，用于启用特定路径的服务端渲染或预渲染，从而改善首屏与 SEO。

再往下，@angular/ssr 还分出了 @angular/ssr/node：它是面向 Node.js 环境的扩展，提供 AngularNodeAppEngine、createNodeRequestHandler、writeResponseToNodeResponse 等更贴近 Express 中间件风格的工具。官方在指南里直接给了 Express 例子。

这就解释了一个常见现象：你在依赖里看到 @angular/ssr，往往意味着项目在用 Angular 新一代的 SSR / Hybrid Rendering 方案，而不只是'能在服务端渲一下'那么简单。

为何二者常成对出现——一层是引擎，一层是脚手架

把前面两段合在一起，你会得到一个非常稳定的结论：

• @angular/platform-server：提供服务端渲染所需的运行时平台与渲染原语（platform、渲染为字符串、服务端相关 providers）。
• @angular/ssr：把渲染能力接入工程化体系，并提供路由级渲染策略与运行时适配封装（RenderMode、ServerRoute、withRoutes、Node.js 扩展等）。

两者关系有点像：

• @angular/platform-server 是发动机与传动系统
• @angular/ssr 是整车的控制台、档位选择、以及让你能在城市道路上合法上路的那套配置与工具链

少了前者，后者没法真正把页面渲出来；少了后者，你往往得自己拼装很多工程细节，维护成本会明显上升。

RxJS 视角下的 SSR 编码差异

你说你精通 RxJS，这点在 SSR 场景非常实用，因为 Angular 的 HttpClient、路由解析、数据流组合，本质都离不开 Observable。

SSR 会让同一段组件代码在两个地方执行：服务器渲一次，浏览器 hydration 再接管一次。官方 hydration 指南把 hydration 定义为：在客户端恢复服务端渲染出来的应用，包括复用服务端已经生成的 DOM 结构与状态等。

这会带来几类非常典型的 RxJS 代码习惯变化：

1) 避免服务端渲染阶段出现'永不结束'的流

服务器渲染通常需要在有限时间内产出 HTML。如果你的渲染依赖某个永不 complete 的流（例如长连接、interval 没有 takeUntil，或某些状态流被当作首屏依赖），服务端可能一直等不到稳定态。

实战里常见做法是把'首屏必须的数据'与'用户交互后才需要的数据'分流：

• 首屏数据：this.http.get(...).pipe(take(1))，或用 firstValueFrom 拿一次性值
• 交互数据：保留长生命周期流，但让它只在浏览器侧真正启用（例如在 isPlatformBrowser 分支里订阅）

2) 避免服务端与浏览器重复请求：用传输缓存与 hydration 配合

官方 SSR 指南提到可以配置 HTTP 响应在服务端渲染时缓存，并在 hydration 阶段复用。这背后的直觉非常简单：服务端已经把数据取回并渲染进 HTML 了，浏览器再进来如果又打一遍同样的接口，请求就重复了。

3) 处理浏览器专属对象：让 Observable 的副作用只发生在正确的平台

在 SSR 里直接读 window、document、localStorage 会踩坑是老生常谈。更隐蔽的问题是：你可能把这些访问藏在 tap()、map() 里，一旦服务器执行到这条链就直接报错。解决方式通常是：把副作用包在平台判断里，或把只属于浏览器的流延后到浏览器生命周期再订阅。

工程结构定位示例

假设你在 package.json 里看到：

• @angular/platform-server
• @angular/ssr
• 可能还会看到 @angular/ssr/node

那么你大概率能在项目里找到这些文件或同类结构：

• server.ts：Express 或其他 Node.js server，把请求交给 Angular 的 server engine 处理（常见 AngularNodeAppEngine）。
• app.routes.server.ts：声明 RenderMode，把路由划分为 CSR、SSR、SSG。
• app.config.server.ts：调用 provideServerRendering(withRoutes(...)) 注入服务端渲染 providers。

这套结构的价值是：当你排查问题时，能快速判断是'渲染引擎层'问题（通常看 platform-server 相关报错），还是'渲染策略与工程集成层'问题（通常看 @angular/ssr、server routes、构建产物与 server handler）。

总结

• @angular/platform-server 解决的是：Angular 在服务器上运行并把应用渲染成 HTML 的底层能力。
• @angular/ssr 解决的是：把服务端与混合渲染能力接入 Angular 工程体系，提供路由级渲染模式、app shell、以及面向 Node.js 等运行时的封装。

理解这两者的区别与联系，有助于在构建高性能、SEO 友好的 Angular 应用时做出更准确的架构决策。