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