这篇文章记录了我从同事SpartacusSSR专家kris那里学到的一些经验。我们可以使用AngularHTTP_INTERCEPTOR拦截器来记录超时请求。但是我们在使用的时候需要小心，只用于调试目的，找到SSR挂起的根本原因。过于激进的日志记录策略（尤其是通过console.log/error与输出流同步完成时）会降低NodeExpress应用程序的性能。如果我们还想通过使用rxjs运算符timeout()终止拦截器中长期未决的API调用，则rxjs流将发出错误。此外，我们希望避免在SSR响应中返回格式错误的HTML。可能有多种方法可以将渲染标记为格式错误。无论标记技术如何，在SSR层（ExpressJS应用程序），我们需要识别格式错误的呈现标记，然后发送CSRindex.html（所谓的CSR回退，具有无缓存http标头）而不是发送呈现的HTML。以下是将渲染标记为格式错误的一些可能方法：(1)调用一些AngularAPI来终止应用程序的待处理渲染并返回一个可以被平台服务器和ngExpressEngine捕获的错误——如果只有这样的AngularAPI存在的话。理想情况下，这样的AngularAPI还应该安全地拆除挂起的渲染（销毁组件、服务和模块，这将允许释放资源）。(2)让渲染完成，但Angular应用程序以某种方式将渲染“标记”为格式错误，因此我们可以稍后在SSR（Expressjs应用程序）层中决定忽略此html并回退到CSR。目前没有确定的行业标准方法来将呈现的结果标记为格式错误，因此中间件可能会忽略它。可以想象，Angular应用程序可以通过两种方式在SSR层中留下标记以供以后识别：添加一些特殊标记的html元素，例如页面的
中的标记。然后为了在SSR层识别它，我们需要在原始呈现的html字符串上运行正则表达式。或者在RESPONSE对象中设置一些特殊的token属性（可以在AngularAPP中注入，最好使用装饰器@Optional()来避免CSR出错。RESPONSE可以从@nguniversal/express-engine/tokens'导入。然后，独立地，可能有2个潜在的地方我们可以拦截渲染结果，识别标记并在响应回退中发送CSR：在我们获得原始html之后，在OptimizedSsrEngine内部，但在将其传递给响应回调（回调（错误，html))或编写自定义的独立Express.js中间件并通过app.use(myMiddleware)将其插入server.ts