innerHTML 直接写入几十MB HTML 会卡死浏览器，因解析、DOM 构建、样式计算和布局全程同步阻塞主线程，导致彻底挂起；Chrome 下超5–10MB即大概率白屏或报RangeError。
为什么 innerHTML 直接塞几十MB HTML 会卡死浏览器
因为浏览器解析、构建 dom 树、触发样式计算和布局是同步阻塞的，大体积 html 会让主线程长时间无响应。不是“慢”，是“彻底挂起”——连 console.log 都可能延迟输出，更别说交互了。
- 典型现象：
RangeError: Maximum call stack size exceeded或直接白屏数秒，DevTools 的 Performance 面板显示 JS 主线程持续 100% 占用 - 实际临界点比想象中低：Chrome 下超过 5–10MB 原始 HTML 字符串就大概率触发明显卡顿（尤其含大量嵌套
<div>或内联样式） -
innerHTML不做分片，也不释放中间内存；V8 引擎在构建巨型 DOM 时 GC 压力陡增，反而拖慢整体
用 DocumentFragment + 分批 appendChild 能缓解吗
能，但仅限于“避免一次性 layout 触发”，不能解决解析卡顿本身。关键在于：先让字符串变成节点，再分批挂载。
- 别用
innerHTML一次性写入整段 HTML —— 改为用DOMParser解析成文档对象，再切片处理 - 每批控制在 200–500 个节点（不是字符数），用
DocumentFragment中转，最后一次appendChild到目标容器 - 必须加
setTimeout或requestIdleCallback让出主线程，否则还是卡。例如：function batchAppend(nodes, container, index = 0, batchSize = 300) {<br> if (index >= nodes.length) return;<br> const frag = document.createDocumentFragment();<br> for (let i = index; i < Math.min(index + batchSize, nodes.length); i++) {<br> frag.appendChild(nodes[i]);<br> }<br> container.appendChild(frag);<br> setTimeout(() => batchAppend(nodes, container, index + batchSize), 0);<br>}
服务端预处理比前端硬扛更靠谱的三个事实
前端永远不是处理大 HTML 的合适场所。真正落地的项目基本都把压力前移到服务端或构建流程。
- 如果 HTML 是你生成的（比如 CMS 导出、爬虫抓取结果），优先在导出时按语义分块：每个
<section>或<article>单独存为 JSON 数组项，前端用fetch流式加载 - 若必须传单个大 HTML 文件，用
gzip压缩 +text/html;charset=utf-8响应头，实测可减少 70%+ 传输体积；但注意：解压后仍要面对 DOM 构建压力，只是起点变小 - Node.js 端可用
cheerio提前剥离无用标签（如注释、<script>、冗余style），再序列化——比前端用DOMParser快一个数量级
iframe 沙箱隔离是最快上线的兜底方案
当所有优化都来不及，又不能改服务端时，iframe 是最轻量、兼容性最好、见效最快的隔离手段。
- 把大 HTML 写进
data:text/html,URL 或 Blob URL，赋给iframe.src，完全不污染主页面 DOM 树和事件循环 - 注意设置
sandbox="allow-scripts"（如需执行 JS），并禁用allow-same-origin防跨域风险 - 缺点：无法直接操作子页面 DOM，通信需靠
postMessage；滚动位置、样式继承需手动同步；移动端某些 WebView 对 Blob URL 支持不稳定
真正难的从来不是“怎么分批”，而是判断哪部分 HTML 实际需要即时渲染——比如搜索高亮、锚点跳转、折叠面板，这些交互逻辑一旦耦合在巨量静态内容里，再怎么切片也救不回体验。拆 UI 和数据的边界，比调优 appendChild 的批次大小重要得多。
立即学习“前端免费学习笔记（深入）”；
