HTML实时预览卡顿主因是强制同步布局（Layout Thrashing），源于频繁读写DOM尺寸、innerHTML重置触发完整渲染流水线、eval阻塞主线程及容器无固定高导致反复回流；应节流更新、批量读写、用transform替代布局属性、iframe隔离并重置样式。
HTML 函数实时预览卡顿，不是代码写错了，大概率是浏览器渲染策略或 DOM 操作方式触发了强制同步布局（Layout Thrashing）——尤其在频繁调用 offsetHeight、getBoundingClientRect() 或读写交替时。
为什么 innerHTML + eval 实时预览会越来越卡
常见做法是监听输入框变化，把 HTML 字符串塞进 iframe 或 div 的 innerHTML，再用 eval 执行其中的 JS。问题在于：
- 每次
innerHTML = htmlStr都触发完整 DOM 解析、样式计算、布局、绘制流水线，无缓存复用 -
eval执行脚本会阻塞主线程，且无法被 V8 优化，多次执行还可能泄漏闭包或事件监听器 - 若预览容器未设固定宽高，浏览器每轮都需回流测量内容尺寸，形成“读尺寸 → 改 DOM → 再读尺寸”死循环
用 requestIdleCallback 节流预览更新
别一输就立刻渲染。把预览逻辑丢进空闲时段执行，既保响应又避卡顿：
let pendingPreview = null;
function schedulePreview(html) {
if (pendingPreview) cancelIdleCallback(pendingPreview);
pendingPreview = requestIdleCallback(() => {
previewFrame.contentDocument.body.innerHTML = html;
pendingPreview = null;
}, { timeout: 500 });
}
注意：requestIdleCallback 在 Safari 中支持不全，生产环境建议 fallback 到 setTimeout(..., 0) 或使用 queueMicrotask（更及时但不空闲感知）。
立即学习“前端免费学习笔记（深入）”；
避免强制同步布局的三个硬规则
只要预览区有 JS 动态读取尺寸/位置，就极易触发 Layout Thrashing。守住这三条：
- 所有读操作（
offsetTop、clientWidth、getComputedStyle）集中放在一次批量读取中，读完再写 - 写操作（
style.transform、classList.add）全部放在一起，避免“读→写→读→写”交叉 - 对频繁变动的元素，用
transform和opacity替代top/left/display—— 它们走合成层，不触发布局
iframe 预览比 div 更稳，但得关掉默认样式干扰
用 iframe 隔离样式和脚本作用域是正解，但默认它带滚动条、边框、外边距，还会继承父页面字体设置。必须显式重置：
<iframe
sandbox="allow-scripts"
srcdoc="<style>*{margin:0;padding:0;box-sizing:border-box;}body{font-family:sans-serif;}</style>"
style="width:100%;height:400px;border:none;"
></iframe>
sandbox="allow-scripts" 是关键：禁掉弹窗、表单提交、插件等风险行为，只放行 JS 执行；srcdoc 内联初始 HTML，比 document.write 更可控，也避免跨域限制。
真正卡住的点，往往不在 HTML 结构本身，而在你每次修改后悄悄触发的那几次隐式回流——尤其是当预览容器没设 height、又用了 flex 或 grid 布局时，浏览器每帧都在反复测量、收缩、再伸展。盯住 DevTools 的 Rendering 面板里「Layout Shifts」和「Forced reflows」两项，比看 FPS 数字更管用。
