SSR模式下运行的Angular应用，为了避免服务端和客户端两次调用同一个API导致的Flickering问题，会使用AngularTransferState服务发送信息从服务端到客户端，其工作原理如下图所示：首先在应用app.module.ts中引入BrowserTransferStateModule：import{BrowserModule,BrowserTransferStateModule}from'@angular/platform-b??rowser';imports:[BrowserModule.withServerTransition({appId:'my-app'}),BrowserTransferStateModule,...]然后在服务器端模块app.server.module.ts中导入ServerTransferStateModule:import{ServerModule,ServerTransferStateModule}from'@angular/platform-server';imports:[AppModule,ServerModule,ServerTransferStateModule,...]我们可以使用makeStateKey函数创建一个键来存储状态中的数据（将传递给浏览器）。使用this.state.get从状态中获取数据，并使用this.state.set在状态中设置数据。进行API调用时，返回的数据使用之前调用makeStateKey创建的键存储在Angular状态中。使用TransferState服务的SpartacusSSR应用在发生内存泄漏时通常会出现以下症状：用户请求响应时间增加，jsappspod频繁重启运行，出现如下日志：（1）SSR渲染超时3000，falling返回CSRfor/xyz(2)PM2Process0重新启动，因为它超过--max-memory-restart值（current_memory=4009730048max_memory_limit=3865051136[octets]）(3)/xyz的渲染无法完成。这可能会导致内存泄漏！针对以上症状之一，我们可以使用Dynatrace来分析内存泄漏的原因。在Dynatrace中，每个SSRpod都可以从左侧导航菜单中的技术和流程选项和Node.js技术中找到。进程组将具有包含应用程序SSR的主文件的名称，通常是main.js或server.js。单击后者将列出在指定时间范围内处于活动状态的pod，使我们能够访问任何单个pod的进程详细信息页面。在高层次上，仅查看Dynatrace中的V8堆内存图就可以对内存泄漏的可能性做出明智的判断。Node.js中潜在内存泄漏的最明显迹象是V8堆内存尖峰（尖峰）内存占用图在每次pod重启后再次尖峰通常，锯齿模式（锯齿）似乎表明应用程序是健康的，因为假设内存中的每个释放都是由于垃圾收集而发生的。但是，如果您注意到内存中的每个峰值之后都是仅由pod重启引起的内存释放，那么应用程序很可能存在内存泄漏。如果我们增加系统的可用内存，但在Dynatrace中观察到的锯齿模式仍然存在，这种性能是应用程序存在内存泄漏的最有力证据之一。
