本文记录我从我的共事，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