当某些异步任务永远挂起时，SSR渲染可能永远不会完成，例如对后端API的http调用。在AngularUniversal中，默认情况下无法中止挂起的渲染。那么渲染的资源没有释放，就会造成内存泄漏。当内存泄漏重复出现时，这最终会导致服务器因内存不足而重新启动。我们采取了一些措施来改善渲染挂起时的监控体验-我们添加了配置SsrOptimizationOptions.maxRenderTime。maxRenderTime之后，我们把这个加到日志里，渲染时间长了，可能会挂掉，但是除了记录日志，我们没有别的办法干预这个请求。理想情况下，我们应该尽可能避免悬挂渲染。理论上，调查SSR中挂起的异步操作的最常见原因是个好主意。然后尽量避免这种情况发生。除了AngularUniversal之外，是否有SSR的替代方案允许以编程方式中止挂起的渲染进程并释放分配的资源？我们也可以使用这个拦截器来记录超时请求。但是我们需要小心，只将它用于调试目的，以找到问题的证据。激进的日志记录（尤其是通过console.log/error与输出流同步完成时）会降低NodeExpress应用程序的性能。如果我们还想在拦截器中使用rxjs操作符timeout()终止长期未决的API调用，那么rxjs流将发出错误，这需要在Angular应用程序中进行相应的错误处理。此外，我们希望避免在SSR响应中返回格式错误的HTML。可能有多种方法可以将渲染标记为格式错误。无论标记技术如何，在SSR层（ExpressJS应用程序）中，我们需要识别格式错误的渲染标记，然后发送CSRindex.html（所谓的CSR回退，具有无缓存的http标头）而不是发送渲染的HTML。以下是将渲染结果标记为格式错误的一些可能方法：(1)调用一些AngularAPI来终止应用程序的待处理渲染并返回一个可能被平台服务器和ngExpressEngine捕获的错误。理想情况下，这种类型的AngularAPI还应该安全地拆除挂起的渲染（销毁允许释放资源的组件、服务和模块）。需要从AngularUniversal的文档和源码中确认是否真的有这样的API。(2)让渲染完成，在Angular应用程序中将渲染结果标记为格式错误，以便我们稍后在SSR（Expressjs应用程序）层决定忽略此html并回退到CSR。Angular应用程序可以通过两种方式在SSR层留下标记供以后识别：在页面头部添加一些特殊的标记html元素，例如标签。然后为了在SSR层识别它，我们需要在原始呈现的html字符串上运行正则表达式。b.在RESPONSE对象中设置一些特殊的token属性（可以在AngularAPP中注入，最好使用装饰器@Optional()来避免CSR出错。可以从@nguniversal/express-engine/tokens'ImportRESPONSE中获取.然后，也许在2个潜在的地方，我们可以拦截呈现的结果，识别标记并在响应中发送CSR回退：a.在OptimizedSsrEngine内部，在我们获得原始html之后，但在callback(callback(err,html))。或者b.编写一个自定义的、独立的Express.js中间件并通过app.use(myMiddleware)将其插入到server.ts中
