在 package.json 里同时看到 @angular/platform-server 和 @angular/ssr,这几乎可以直接推断:这个 Angular 应用已经不满足于纯 CSR(浏览器端渲染),而是在引入 SSR(服务端渲染)或更细粒度的 Hybrid Rendering(混合渲染)。官方文档把这种方向称为 Server and hybrid rendering,并明确给出了 ng new --ssr 与 ng add @angular/ssr 作为启用入口。
下面我用一条严谨的推理链,把这两个依赖的职责边界拆开,并解释为什么它们会一起出现。
从依赖反推应用要解决的核心矛盾
Angular 默认把应用作为 CSR 来交付:服务器只负责吐出静态资源,浏览器下载 JS,再由框架跑起来把页面绘制出来。官方在 SSR 指南里点得很直白:纯 CSR 的代价往往是更慢的首屏、更差的指标表现,以及更多计算压力落到用户设备上。
一旦你希望做到下面任意一点,SSR / Hybrid Rendering 就会变得现实且常见:
- 首屏更快,把可见内容的
HTML提前在服务器生成再返回(用户先看到内容,再逐步变得可交互) SEO更稳,让爬虫直接拿到完整HTML- 静态化一部分路由(
SSG),把构建时产出的HTML直接当静态文件发出去 - 对不同路由做差异化渲染策略(同一站点内混用
CSR、SSR、SSG)
而这四类诉求,对应的是两层能力:
- 底层运行时能力:Angular 必须能在服务器环境里启动、跑变更检测、把组件树渲成字符串
HTML - 工程化与框架级封装:CLI 要能帮你生成
server.ts、配置构建与开发服务器、提供路由级渲染模式、对接Node.js或其他运行时
这也正好对应 @angular/platform-server 与 @angular/ssr 的分工。
@angular/platform-server:底层运行时基石
@angular/platform-server 的定位可以一句话概括:让 Angular 能在服务器侧启动一个 platform,并把应用渲染为 HTML。
官方 API 对 platformServer() 的描述非常直接:它创建一个服务端的 Angular platform,并用于执行 Angular 应用的服务端渲染。
从能力上看,它更像一组底层积木,主要解决这几个问题:
- 在服务器上创建 Angular 平台实例
浏览器侧用platformBrowser,服务器侧需要platformServer。没有这层,Angular 就缺少对应的运行时适配。 - 把应用渲染成字符串
HTML
你会在它的 API 里看到renderApplication():它会引导启动一个 Angular 应用实例,并把结果渲染成字符串返回。这件事本质上就是:在服务器进程中执行一次渲染流程,得到完整的document片段或整页HTML。 - 提供服务端渲染所需的一组 providers 与服务
比如服务端的PlatformState、序列化前钩子、以及provideServerRendering等(不同 Angular 版本里用法会有演进,但其目标就是把服务端渲染需要的依赖注入装配好)。


