> 文件位置：`core-libs/setup/ssr/optimized-engine/optimized-ssr-engine.ts`

围绕 `SSR 并发渲染` 的话题，总会遇到一个常见疑问：既然 `Node.js` 是单线程，那怎么做到并发渲染。结合本项目中的 `OptimizedSsrEngine` 实现，可以给出一个工程化且接地气的回答：`并发` 在这里并非 `多个 CPU 核心同时执行同一段 JS` 的并行含义，而是指 `多个请求的渲染流程在同一事件循环里交错推进`，尤其是在涉及大量异步 I O 的场景下，渲染任务会以 `等待 I O` 与 `执行 JS` 交替的方式共同前进。这样一来，`JS 执行本身` 仍然是单线程，但 `任务整体` 的推进是并发的。

换一个更具象的比喻更容易理解：一位厨师在同一个灶台上做多道菜。他只能在同一时刻翻炒一口锅，这对应 `JS 的单线程执行`；可他可以把汤放在慢炖、把饼送进烤箱，这些在后台持续进行的等待，对应 `HTTP 请求`、`数据库查询`、`文件读取` 等 I O 操作。当这些 I O 结果返回时，厨师再切回去继续下一步。对于食客来说，虽然只有一位厨师，但多道菜似乎在并发地被处理。

---

## `OptimizedSsrEngine` 是如何管理 `并发渲染` 的

在 `optimized-ssr-engine.ts` 里，可以看到几个关键的并发相关字段与逻辑：

- `currentConcurrency`：记录当前正在进行中的渲染任务数。
- `ssrOptions.concurrency`：并发上限的配置。当 `currentConcurrency` 达到上限，引擎会让后续相同键的请求 `CSR 回落`，或在 `reuseCurrentRendering=true` 的条件下等待复用。
- `reuseCurrentRendering`：同一渲染键的请求是否合并为一次底层渲染，其他请求仅复用结果。这是典型的 `single flight` 模式，能在热点页面大幅降低实际底层渲染次数，从而降低 CPU 与内存压力。
- `renderingCache` 与 `renderCallbacks`：在 `reuseCurrentRendering` 场景中，一个渲染键只触发一次底层渲染，其他请求被记录在回调列表里，待结果出来后广播。

需要强调的是，这里的 `currentConcurrency` 并不等同于 `多线程并行`。它更像是 `此刻有多少渲染流程处于进行态` 的计数，这些流程在单个事件循环里交错执行。当某个渲染流程进入 `await 后端接口` 的阶段，事件循环就有机会去处理另一个渲染流程的 JS 执行或 I O 事件回调，从而实现并发推进。

---

## 事件循环与并发渲染的交错推进

理解 `Node.js` 的并发渲染，需要抓住两个核心机制：

- `JS 执行单线程`：同一时刻只能执行一段 JS 代码，这部分相当于厨师此刻只在翻一个锅。
- `非阻塞 I O 与回调驱动`：大量异步 I O 操作交给系统或 `libuv` 去等待，结果返回后通过事件循环安排回调继续执行，这相当于把汤炖上、把饼进烤箱，厨师空出手处理别的菜。

一个简化的时间线可以这样描述：

```
T0: 请求 A 进入，开始 SSR，触发多个后端 API 请求，进入 I O 等待
T1: 请求 B 进入，开始 SSR，渲染了部分模板，又触发一个后端 API 请求，进入 I O 等待
T2: 请求 C 进入，开始 SSR，本地计算较多，占用一段时间的 JS 执行
T3: 请求 A 的某个 API 响应已回到事件循环，回调执行，继续拼装页面，再次触发另一个 I O
T4: 请求 B 的 I O 也回来了，继续模板渲染，触发下一步数据查询
...
```

从外部观察，A B C 三个请求都在推进，只不过在任何一个微小的瞬间，只有一个渲染流程真正占用 JS 解释器，其余在等待 I O 的任务不会阻塞它。这种交错推进就是 `OptimizedSsrEngine` 所计数的 `并发渲染` 的真实含义。

---

## `libuv 线程池` 与并发的边界

虽然 `JS` 层是单线程，但并发的背后离不开 `libuv` 线程池与内核能力：

- `网络 I O`：绝大多数属于非阻塞套接字配合内核事件通知，不占用 `libuv 线程池` 的配额。当你向后端发起 `HTTP` 请求，等待与响应并不会堵住 JS 线程。
- `文件 I O`、`DNS 解析`、`加解密`、`压缩`：这类会使用 `libuv 线程池`。默认线程池大小是 4，必要时可通过环境变量 `UV_THREADPOOL_SIZE` 调整。

这意味着：对于 `以网络 I O 为主` 的 SSR 渲染，只要 JS 层没有写重 CPU 的同步逻辑，做到 `几十甚至上百` 的并发渲染是合理的；但一旦 SSR 模板渲染包含大量 `同步 CPU 计算`，或者频繁 `文件 I O`，并发推进的效果就会被打折扣，重 CPU 会直接阻塞事件循环，文件 I O 又会占用有限的线程池配额。

---

## `CPU 绑定` 的 SSR 段落会抹杀并发收益

不少团队会在 SSR 中做重量级的同步计算，例如：

- 在渲染阶段做大量 `JSON` 转码与深度拷贝；
- 基于纯 JS 实现的模板引擎进行长链路同步遍历；
- 在服务器渲染里内联过多个性化逻辑导致复杂度爆炸；

这些 `CPU 绑定` 的段落一旦持续几十毫秒乃至上百毫秒，会直接阻塞事件循环，让 `A B C` 的交错推进退化成 `串行等待`。此时你即使把 `OptimizedSsrEngine` 的 `concurrency` 调得很大，也见不到线性提升。工程上的解法通常是：

- 把重计算下沉到后端服务，让 SSR 更像拼装器；
- 用 `ALWAYS_CSR` 把无需 SSR 的页面排除，或者把个性化重的区块延后到 CSR 注水；
- 如果必须在 Node 端做 CPU 重逻辑，考虑 `Worker Threads` 或 `子进程` 隔离，用消息传递方式异步完成，再把结果合并到 SSR；

配合这些手段，`OptimizedSsrEngine` 的 `并发计数` 才有实际的吞吐意义。

---

## `single flight` 在热点页面减少实际渲染次数

`reuseCurrentRendering=true` 时，同一渲染键的请求只触发一次底层渲染，其余请求进入 `renderCallbacks` 队列等待结果。当底层渲染完成，所有等待者一次性拿到相同 HTML。这并不依赖多线程，它是在应用层用 `渲染键` 做的 `去重合并`：

- 对热点详情页，可能 200 个并发请求在近似相同时间进入；
- 引擎只允许其中一个请求占用 `currentConcurrency` 位发起真正 SSR；
- 其余 199 个请求不会增加 `currentConcurrency`，因此不会进一步压垮事件循环；

这就是 `OptimizedSsrEngine` 能顶住高峰的关键能力。并发的意义在这里体现为 `大量请求并发到达`，但 `底层渲染次数被合并为一次`，吞吐与稳定性同时改善。

---

## 请求级超时与后台继续渲染的协作

`shouldTimeout` 与 `getTimeout` 让请求在合适的窗口内等待 SSR。如果时间到了仍未完成，用户立刻拿到 `CSR 首屏`，但底层渲染会继续进行。等它完成后，若全局 `cache=true`，结果会被 `store` 入内存缓存，下一个同键请求就有机会命中 SSR；若配置为 `cache=false`，则会在使用一次后立即清理，降低陈旧暴露的窗口。

这种协作可以把 `并发渲染` 的用户体验风险降到最低：

- 高峰时请求大量同时到达，超时的立即回落，减少长连与排队；
- 后台慢慢把重页面渲染完，缓存在内存里，后续命中率越来越高；

你会看到 `并发` 在此处体现为一个 `逐步升温` 的过程：一开始多数请求拿到 CSR，但随着缓存填充，同一渲染键的后续请求会快速命中 HTML，即使 JS 单线程，整体吞吐也被拉起来。

---

## `maxRenderTime` 看门狗对并发健康度的意义

由于底层渲染不可中断，一旦依赖异常，渲染可能长时间挂起。`maxRenderTime` 作为看门狗，会在上限时刻触发：

- 把该渲染键从 `rendering` 状态里清掉；
- 扣减 `currentConcurrency`，释放并发位；
- 在 `reuseCurrentRendering=true` 时清空该键的 `renderCallbacks`，避免等待者永久阻塞；
- 且当迟到的底层回调抵达时，直接忽略这份结果并记录日志；

这保证了并发计数在最坏情况下依旧能回落，让系统 `不会被少数挂起的渲染长期占坑`。单线程并不等于不可恢复，这是引擎在 `不可中断` 约束下做到的 `软中断` 与 `资源回收` 的要点。

---

## 真实世界案例一：`网络 I O 为主` 的国际站点详情页

背景设置：

- 节点架构为 `Kubernetes 多 Pod`，每个 Pod 内跑一个 `Node.js` SSR 进程；
- 每个进程的 `concurrency` 设为 8，`reuseCurrentRendering=true`，`timeout=1500ms`，`maxRenderTime=300000ms`；
- 详情页渲染涉及价格、库存、促销、推荐四个后端接口，单个接口 `p95` 小于 200ms；

观测结果：

- 在峰值 `每秒 300 请求` 的冲击下，进程的 `JS CPU` 使用率稳定在 40 到 60 之间；
- `currentConcurrency` 常驻 5 到 8 的区间，说明有 5 到 8 个渲染流程在交错推进；
- 大量请求在 1 到 1.5 秒内命中 SSR，少数超时回落 CSR，但随着缓存填充，命中率持续升高；

解读：

- 因为是 `网络 I O 为主`，单线程的 JS 在 I O 等待时有充足的空隙处理其他请求，形成良好的并发推进；
- `reuseCurrentRendering` 把热点 URL 合并，压低了底层渲染次数，进一步降低 CPU 峰值；

这类场景最能够发挥 `Node.js 并发 I O` 的优势。

---

## 真实世界案例二：`CPU 绑定` 的复杂模板站点

背景设置：

- 同样的 `Kubernetes` 架构，但页面模板包含大量同步字符串拼接与深度数据变换；
- 单次 SSR 的 `JS 执行` 就可能占用 200 到 400ms；

观测结果：

- 即便设置 `concurrency=8`，实际 `currentConcurrency` 常见在 1 到 2，因为 CPU 段落把事件循环阻塞了；
- 峰值期间，用户的超时 CSR 回落比例明显升高；

解读与改造：

- 把复杂的数据变换下沉到后端服务，SSR 端只做轻量模板拼装；
- 或者用 `Worker Threads` 把复杂同步计算剥离到工作线程，SSR 端用消息机制异步获取结果；
- 改造后，`currentConcurrency` 能恢复到 5 到 8 的并发推进水平，超时 CSR 比例下降明显；

这个案例说明 `JS 单线程` 的瓶颈在 `同步 CPU 段落`。要让并发渲染真正发生，就得把同步时间降下来或搬走。

---

## 单进程与 `多进程 多线程` 的协作思路

`OptimizedSsrEngine` 的并发控制在单进程内工作良好。为进一步扩展吞吐，还可以引入进程级或线程级能力：

- `Node Cluster` 或 `PM2 cluster`：同一台主机上起多个 `Node.js` 进程，利用多核 CPU，每个进程内部继续使用 `OptimizedSsrEngine` 控制单进程并发。这是生产最常见的方式。
- `Worker Threads`：对确实重的同步任务，剥离到工作线程里；SSR 端只负责路由与调度，避免阻塞事件循环。
- `容器与多副本`：在 `Kubernetes` 下横向扩容多个 Pod，每个 Pod 一个 `Node.js` 进程，结合上游负载均衡；

这样一来，并发渲染在单进程内靠 `I O 交错`，在多进程多副本层面靠 `并行扩展`。两层配合，产能呈倍数增长。

---

## `concurrency` 这个旋钮应该如何设定

- 对 `网络 I O 为主` 且 SSR 模板较轻的场景，可以把 `concurrency` 设置为 4 到 16 的区间，再结合压测观察 `CPU 使用率` 与 `超时率`；
- 对 `CPU 绑定` 任务较多的场景，建议从 2 到 4 起步，优先做 `同步段落瘦身` 再逐步调高；
- 在 `reuseCurrentRendering=true` 时，热点 URL 的请求不会线性增加并发位，能承受更高的突发流量；
- 结合 `timeout` 与 `maxRenderTime` 的双保险，确保并发位不会被卡死；

并发不是越大越好，而是要与 `事件循环健康度`、`GC 开销`、`后端依赖能力` 一并考虑。

---

## 与 `renderingStrategy` 的联动：`ALWAYS_SSR` 与 `ALWAYS_CSR`

- `ALWAYS_SSR`：即使系统压力较大，也会尽量让此类请求进入 SSR 流程，配合 `forcedSsrTimeout` 拉高等待阈值，典型用于 `SEO 爬虫` 与监控探针；
- `ALWAYS_CSR`：直接排除在 SSR 之外，减少并发位占用，常用于强个性化或纯交互页面；
- `DEFAULT`：走正常的 `timeout` 与 `concurrency` 判定路径；

通过策略分流，可以把宝贵的并发位留给更需要 SSR 的页面类型。

---

## 与缓存的配合：并发渲染的 `助推器`

- 内存缓存 `RenderingCache`：配合 `cache=true`，使同一渲染键在后续请求中快速命中 SSR，显著降低实时渲染压力；
- CSR 回落的 `Cache-Control: no-store`：避免错误地把 CSR 页面缓存到外部，从而污染后续命中；
- 边缘缓存与 `stale while revalidate`：在 CDN 层面继续扩散命中率，让源站更多处理长尾与更新窗口；

缓存是并发渲染的 `助推器`，把 `单进程 I O 交错` 的优势，通过 `命中` 放大到用户层面。

---

## 一个具象的压测脚本思路与观测维度

为了验证并发渲染行为，可以做一个简单的压测思路：

- 准备一条热点 URL，与一条冷门 URL；
- 热点 URL 开启 `reuseCurrentRendering=true`；冷门 URL 关闭它；
- 配置 `concurrency=8`、`timeout=1500ms`、`maxRenderTime=300000ms`；
- 用你习惯的压测工具在 `20 到 100 并发` 的区间逐步升压；

观测这些维度：

- 引擎日志里的 `Rendering started`、`Rendering completed`、`CSR fallback`、`Request is waiting for the SSR rendering to complete` 的比例与节奏；
- `currentConcurrency` 的实时曲线是否稳定在目标区间；
- 用户侧 `首屏时间` 与 `CSR 回落比例`；
- 后端依赖的 `p95` 与 `错误率`；

你会发现，热点 URL 在 `single flight` 的帮助下，`Rendering started` 次数显著低于请求数；而冷门 URL 则与请求数接近，容易触发并发上限与 CSR 回落。这个对比能直观体现引擎并发管理的价值。

---

## 小结与共识

`Node.js 单线程` 与 `SSR 并发渲染` 并不矛盾。关键在于理解并用好 `非阻塞 I O` 与 `事件循环`：

- `JS 执行` 仍是单线程，但 `渲染流程整体` 在 I O 间隙里交错推进，体现为并发处理；
- `OptimizedSsrEngine` 用 `currentConcurrency`、`reuseCurrentRendering`、`timeout`、`maxRenderTime`、`renderingCache` 等机制，把这种并发管理成可控、可观测、可恢复的系统行为；
- 当渲染包含大量 `CPU 绑定` 同步段落时，并发会退化，宜通过 `瘦身`、`下沉` 或 `Worker Threads`、`多进程` 进行解耦；
- 与边缘缓存的协同能把并发优势进一步放大，降低源站压力；

回到工程实践，把 `并发` 理解为 `多请求在同一事件循环交错前进`，把 `限制` 理解为 `不要让同步段落过长`，再通过引擎提供的旋钮组合进行调优，就能在单进程内获得稳定而高效的 SSR 吞吐。当横向扩展到 `多进程 多副本`，系统容量会实现近似线性增长。


文件位置：core-libs/setup/ssr/optimized-engine/optimized-ssr-engine.ts

Node.js 单线程 与 SSR 并发渲染：基于 optimized-ssr-engine.ts 的原理拆解与案例

紫薇堂堂主

前端

后端

架构设计

Node.js SSR并发渲染并非多线程并行，而是通过事件循环实现多请求交错处理。OptimizedSsrEngine利用currentConcurrency计数、singleflight模式等机制，在单线程环境下高效管理渲染流程。关键点包括：异步IO等待间隙处理其他请求、热点页面请求合并、CPU密集型任务优化。合理配置并发参数可显著提升SSR吞吐量，配合缓存策略可进一步优化性能表现。

负载均衡

Kubernetes

数据库

服务器

解释器

容器

路由

JSON

CDN免费试用


2026采购季 | AI焕新·智启新局

tencentdb-catalog

4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Node.js SSR并发渲染并非多线程并行，而是通过事件循环实现多请求交错处理。OptimizedSsrEngine利用currentConcurrency计数、singleflight模式等机制，在单线程环境下高效管理渲染流程。关键点包括：异步IO等待间隙处理其他请求、热点页面请求合并、CPU密集型任务优化。合理配...

Node.js 单线程 与 SSR 并发渲染：基于 optimized-ssr-engine.ts 的原理拆解与案例-腾讯云开发者社区-腾讯云

Node.js 单线程与 SSR 并发渲染：基于 optimized-ssr-engine.ts 的原理拆解与案例

Node.js 单线程与 SSR 并发渲染：基于 optimized-ssr-engine.ts 的原理拆解与案例

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

Node.js 单线程 与 SSR 并发渲染：基于 optimized-ssr-engine.ts 的原理拆解与案例

Node.js 单线程 与 SSR 并发渲染：基于 optimized-ssr-engine.ts 的原理拆解与案例

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

Node.js 单线程与 SSR 并发渲染：基于 optimized-ssr-engine.ts 的原理拆解与案例

Node.js 单线程与 SSR 并发渲染：基于 optimized-ssr-engine.ts 的原理拆解与案例