预渲染快照不阻塞解析，但错误注入方式会拖慢首屏、破坏hydration、触发重排；应使用template元素注入，剔除html/body/script，显式声明hydration边界。
预渲染静态快照本身不阻塞页面解析，但错误的插入方式会让它变成阻塞源。 关键不在“是否预渲染”，而在“如何把生成的 HTML 片段注入 DOM”——用错方法，静态快照反而拖慢首屏、破坏 hydration、触发重排。
用 template 注入快照，别用 innerHTML 直接赋值
服务端返回的 HTML 快照（比如从 SSR 或构建时预生成）若直接写入 innerHTML = htmlStr，浏览器会立即重新解析整段字符串：触发样式计算、布局、甚至执行内联脚本（如果没过滤干净），导致主线程卡顿。
- 正确做法：创建临时
<template>元素，设其innerHTML，再取.content克隆后插入 -
template.content是DocumentFragment，天然惰性，不触发解析或渲染，克隆成本极低 - 错误示例：
document.getElementById('app').innerHTML = responseHtml—— 重复解析 + 潜在 XSS + ID 冲突 - 正确示例：
const temp = document.createElement('template'); temp.innerHTML = responseHtml; root.appendChild(document.importNode(temp.content, true));
预渲染快照必须剔除 <html>、<body> 和脚本逻辑
构建时生成的“静态快照”常被误当成完整 HTML 文件直接塞进容器，结果出现嵌套 <html>、重复 <meta>、或 <script> 被二次执行——这些不是渲染问题，是结构污染。
- 快照内容应仅为纯结构片段，例如：
<main><h1>标题</h1><p>正文</p></main>，不含文档根节点 - 服务端输出前需 strip 掉
<html>、<head>、<body>及所有<script>标签（包括内联和外部引用） - 若保留
<script>，必须手动剥离并转为 JS 逻辑延迟绑定，否则可能执行两次或报ReferenceError - 注意
id冲突：SSR 已输出的节点 ID 若与快照中重复，后续getElementById行为不可预测
hydration 边界必须显式声明，不能靠 DOM 自动对齐
当页面已由 SSR 输出一部分结构，又用预渲染快照补全剩余区块时，“哪些节点该复用、哪些该替换”没有默认规则。浏览器不会自动识别 hydration 边界，全靠开发者标记。
立即学习“前端免费学习笔记（深入）”；
- 在 SSR 输出的容器上加唯一属性，如
data-hydrate="comments"，快照注入前先检查该属性是否存在 - 避免用
innerHTML覆盖整个容器，应只更新子区域；否则 SSR 的事件监听器、状态绑定全部丢失 - 快照中含动态数据（如时间戳、用户昵称）时，务必与客户端状态同步，否则 hydration 后 React/Vue 会触发警告或强制重渲染
- IE 不支持
<template>，需 fallback 到<script type="text/template">+ 正则提取，但此时无法保证标签闭合安全，建议放弃 IE 支持
真正难的不是生成快照，而是让快照“安静地融入现有 DOM 流程”。任何绕过 template.content 克隆、跳过 hydration 边界校验、或忽略服务端/客户端结构一致性的地方，都会在高并发或弱网下暴露为白屏、闪动或交互失效。
