内容站的 SSR 管线长期运行在 Node 之上，中间隔着一层框架自带的服务器适配器。这层适配器把 Web 标准的 Request / Response 转换成 Node 的 IncomingMessage / ServerResponse，再由框架转回来。每次请求多两次转换，以及一次不必要的可写流封装。
去掉中间层
React 的服务端渲染入口 renderToReadableStream 返回的是 Web ReadableStream。Deno.serve 的回调直接接收 Request 并返回 Response，两者之间不需要任何转换。重构的核心工作，是把框架的请求处理函数接到这层原生契约上。
结果是请求路径上少了两处流转换与一次事件循环跳转。在同等机器规格下，首字节时间中位数从 41 毫秒降到 25 毫秒，冷启动后的首个请求从 220 毫秒降到 136 毫秒。这些数字来自 30 天的生产观测，不是基准测试。
代价与边界
代价是生态兼容性。部分只提供 CommonJS 入口、且依赖 Node 内部模块的包无法直接使用。我们遇到的实际情况是三个包：一个用于 CSS 提取，两个用于构建期资源处理。这三个都只在构建时运行，迁移到 Node 执行构建、Deno 执行运行时之后，问题消失。
结论是清晰的：SSR 的运行时可以很薄，前提是把构建期与运行期彻底分开。反过来说，如果运行时强依赖 Node 特有的流语义或原生扩展，这次迁移的收益不足以覆盖风险。