为什么我们会看到 SAP Spartacus 服务器端渲染 `rendering in process` 的日志

问题：为什么我们会看到形如下列格式的日志？

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”的值如何。