ssr对html在线运行工具是必需的，因其能解决首屏白屏、语法高亮延迟和执行结果卡顿问题；必须用rendertostring在服务端生成含初始状态与高亮的html，并内联首屏css、defer加载js，确保hydration一致。
服务端渲染（SSR）对 HTML 在线运行工具这类交互密集型页面，不是“能用就行”，而是“不用 SSR 就没法解决首屏白屏+语法高亮延迟+执行结果卡顿”这三连问题——关键在于：用户粘贴代码后，必须在 DOM 就绪前就拿到带语法高亮、带预执行状态的 HTML 片段，否则体验断层。
为什么 renderToString 必须在服务端调用，且不能复用客户端逻辑
在线运行工具的“首屏”不是静态页面，而是带初始代码块、默认语言选择、甚至预跑结果的容器。若依赖客户端 JS 拉取模板再 innerHTML 注入，用户会先看到空白编辑器框，再闪出高亮代码——这就是典型的 CSR 白屏。而 renderToString 是 React 官方服务端入口，它能在 Node 环境直接把组件树转成字符串，不触发任何浏览器生命周期。漏掉这点，所有 SSR 优化归零。
- 客户端的
ReactDOM.createRoot或hydrateRoot只负责接管已存在的 DOM，不能生成首屏内容 - 若在服务端误用
useEffect触发 fetch，它根本不会执行——服务端没有 effect 生命周期 - 必须手动在服务端做数据准备：比如读取默认代码片段、预执行简单 JS 片段（用
vm2或isolated-vm）、生成 AST 高亮结构
res.send() 中的 HTML 模板必须包含 hydration 所需上下文
用户看到的不是最终态，而是可交互起点。服务端吐出的 HTML 必须让客户端能“接住”并继续运行，否则编辑器光标错位、历史记录丢失、执行按钮点击无响应——这些都不是 JS 错误，是 hydration 失败。
- 必须注入
window.__INITIAL_STATE__，包含初始代码、选中语言、是否已执行等状态，体积控制在 5KB 内，过大影响 TTFB -
<div id="root">${html}</div>中的${html}是纯字符串，不能含dangerouslySetInnerHTML类逻辑，避免 XSS 和 hydration 冲突 - 脚本加载顺序固定：
<script src="/client.js" defer></script>放在
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
