Angular SSR 18应用内存泄漏求助：已多方案尝试仍未解决

服务实例隔离验证 #

• 直接用Angular 18的@Injectable({ scope: 'request' })替代手动在main.server.ts中提供服务，确保每个请求的服务实例完全独立。重点检查是否有服务依赖了全局单例（比如第三方库的全局对象），这类对象不会随请求销毁，是泄漏高发点。
• 排查服务依赖链：如果请求作用域的服务依赖了根作用域服务，根服务里的状态或订阅会持续留存，导致内存堆积。

Observable订阅彻底清理 #

• 除了单个订阅的取消，重点检查链式流（比如switchMap/mergeMap内部的嵌套订阅）是否被上层流正确管理。若订阅了永不结束的流（比如全局状态的BehaviorSubject），必须在请求结束时手动取消。
• 统一用takeUntil管理订阅：每个请求作用域的服务中创建destroy$ = new Subject<void>()，所有订阅都添加.pipe(takeUntil(this.destroy$))，并在服务的ngOnDestroy钩子中调用this.destroy$.next()和this.destroy$.complete()——Angular会在请求结束时自动触发服务的ngOnDestroy。
• 清理定时器：检查服务中是否存在setTimeout/setInterval，这类定时器会持有服务实例引用，务必在请求结束时用clearTimeout/clearInterval销毁。

SSR上下文泄漏排查 #

• 检查TransferState使用：避免存储大量大对象，即使Angular会自动处理，自定义的全局缓存仍可能残留导致内存堆积。
• 第三方库适配：部分前端库在SSR环境下会创建全局实例或缓存（比如日期处理库、UI组件库），需手动在请求结束时清理这些实例，或改为请求作用域方式创建。

用工具定位泄漏点 #

• 启动应用时添加node --inspect参数，用Chrome DevTools连接Node进程，在Memory面板抓取多次请求后的堆快照，对比查找数量持续增长的对象（比如重复的服务实例、Subscription对象、虚拟DOM节点）。
• 在Performance面板记录内存分配，定位持续分配内存却不释放的代码块，直接锁定泄漏源。

请求结束后主动清理 #

• 在server.ts的请求处理回调中添加res.on('finish', () => {})钩子，手动清理当前请求相关的全局资源，比如第三方库的临时缓存、自定义全局变量。
• 确认每次请求都调用renderModule，而非复用之前的模块实例——模块复用会导致状态持续堆积。

内容的提问来源于stack exchange，提问作者Luhd