問題：為什么我們會看到形如下列格式的日志？

CSR fallback: rendering in progress

每次新的請求到達 SSR 時，都會調用文件 spartacus-setup-ssr.js 中的 renderResponse 函數。

在其中， this.shouldRender 被調用，以評估應如何處理此請求。

在 shouldRender 中：

step1：評估當前并發數是否達到上限。 評估邏輯是通過將當前并發值（在 this.concurrency 中維護）與客戶傳遞的選項（ this.ssrOptions.concurrency ）進行比較來完成的：

源代碼：

const concurrencyLimitExceed = ((_a = this.ssrOptions) === null || _a === void 0 ? void 0 : _a.concurrency) ? this.currentConcurrency >= this.ssrOptions.concurrency: false;

step2：評估同一頁面是否已經有渲染過程。

const isRendering = this.renderingCache.isRendering(this.getRenderingKey(request));

如何判斷兩個渲染請求是否代表同一個頁面？

這是由第 97 行中的函數 this.getRenderingKey(request) 完成的。

默認的區分邏輯是使用請求的 originalUrl 字段，即如果兩個請求的 originalUrl 相同，則 SSR 將它們視為同一個頁面。

如何判斷給定頁面是否已經有正在進行的渲染過程？

在 spartacus-setup-ssr.js 的 RenderingCache 類中，我們使用 Map 通過鍵值結構來維護每個頁面的渲染過程，參見下面的第 9 行。

默認情況下，key 是請求的 originalUrl，value 是一個包含布爾標志的對象：true 或 false。

如果可以從 RenderingCache 的 Map 中找到等于 true 的給定值，我們認為給定頁面正在渲染。 同時，如果另一個請求帶有完全相同的頁面鍵（即相同的 originalUrl ），我們將不會通過 SSR 提供第二個請求，而是觸發 CSR 回退，并在下面的第 99 行打印日志。

注意：使用 RenderingCache 記錄頁面是否正在渲染的邏輯始終處于開啟狀態，無論選項“cache”的值如何。

更多Jerry的原創文章，盡在：“汪子熙”:

總結

以上是生活随笔為你收集整理的为什么我们会看到 SAP Spartacus 服务器端渲染 `rendering in process` 的日志的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。