ssr输出html劣化源于多环节叠加：dom错位、语义标签降级、富文本未净化、内联脚本残留、标签未闭合，导致hydration失败、lighthouse分数下降、可访问性丧失。
为什么 SSR 输出的 HTML 会劣化？
不是模板写错，而是服务端渲染流程中多个环节叠加导致：DOM 结构错位、语义标签被降级为 div、富文本字段未经净化直接拼接、内联脚本/样式残留、甚至出现未闭合标签。这些在本地开发时不易暴露，上线后却引发 hydration 失败、Lighthouse 分数骤降、屏幕阅读器无法识别内容。
必须在 renderToString 前做 DOM 白名单净化
用户提交的富文本（如 CMS 正文、评论）绝不能直接传给 renderToString。它不校验 HTML 合法性，只负责序列化——恶意 onerror 属性、javascript: 链接、未闭合的 <p></p> 全部原样输出。
- 用
DOMPurify.sanitize()（Node 环境）或HTMLPurifier（PHP）做预处理，配置白名单：ALLOWED_TAGS限定为p, strong, em, img, a, ul, ol, li，禁用script, iframe, object - 必须显式允许
a的href属性，并限制协议：ALLOWED_URI_SCHEMES = ['https', 'http', 'mailto'] - 对
img的src做同源校验或强制补前缀，避免相对路径在 SSR 中解析失败 - 别依赖
htmlspecialchars()——它把<strong>加粗</strong>变成纯文本，富文本字段就废了
服务端生成的 HTML 必须是 fragment，不是完整文档
res.send(htmlString) 直接吐出带 的字符串，会导致客户端 hydration 时 DOM 树错乱。React/Vue mount 时找不到匹配节点，静默丢状态、失焦点、history 不同步。
- 服务端只返回纯 fragment，例如：
<div id="root"> <h1>标题</h1> <p>正文</p> </div> - 模板引擎（如 EJS）里用
插入，而非—— 后者会转义导致结构破坏 - 确保初始状态挂载在
window.__INITIAL_STATE__，且大小 ≤ 5KB；超大会拖慢首屏 JS 解析 - 禁止在组件里写
useEffect(() => fetch(), [])—— SSR 环境不执行，首屏必然空数据
语义化与可访问性必须在服务端固化
前端框架常把 header、nav 渲染成 div 加 class，这是懒惰的妥协。SSR 是唯一能真正落地语义化的机会——浏览器和辅助技术靠标签名理解结构，不是靠 class 名。
- 用
<header></header>替代<div class="header">，<code><main></main>替代<div id="app"> <li>嵌套超过 4 层时，检查是否漏了 <code><section></section>或<article></article>；BEM 类名（如card__title）不能替代<h2></h2>的层级语义 - 所有图片必须带
alt属性，空值写alt=""（非省略），否则屏幕阅读器会读文件名 - 动态生成的
id（如表单错误提示）要保证唯一性，否则aria-describedby绑定失效
服务端渲染不是“拼完 HTML 发出去”就结束。结构错一位、标签少一个 alt、富文本多一个 onload，都可能让首屏变白屏、SEO 掉权重、残障用户无法操作——而这些错误不会报红，只会静默崩坏。
