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

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 的原创文章，尽在：” 汪子熙 ”: