在线运行html默认采用iframe沙箱方案，因其天然隔离父页面js、cookie和localstorage；需显式设置sandbox="allow-scripts"并避免空src，同时防卡顿需防抖、dom diff及缓存策略，且必须禁用eval等动态执行api。
因为本地调试 HTML 的中间环节太多，而在线运行能直接砍掉保存、刷新、切窗口这三步——只要代码一改，结果立刻出来。
为什么 iframe 是在线运行 HTML 的默认沙箱方案
几乎所有轻量级在线运行器都用 iframe 渲染用户代码，不是因为它最强大，而是它天然隔离：父页面的 JS、Cookie、localStorage 默认无法被子 iframe 访问。但要注意两点：
- 必须显式设置
sandbox="allow-scripts"才能让用户 JS 执行，不加这个属性，alert()都不会弹 - 如果漏设
srcdoc而用空src，某些浏览器会触发跨域限制，导致document.write()失败 -
iframe内无法访问父页面的window.parent，但用户代码若硬写top.location = '...'仍可能跳转——得靠sandbox属性禁用allow-top-navigation
实时预览卡顿？大概率是没做 DOM diff 或缓存策略
每次用户敲一个字符就全量重写 iframe 内容，会导致频繁重排重绘，尤其在 CSS 复杂或 JS 逻辑多时明显卡顿。可行做法包括：
- 只在用户停顿 300ms 后触发渲染（防抖），而不是 oninput 立即执行
- 对 HTML 字符串做最小化清理：移除注释、合并空白、剔除重复
<style></style>标签，避免样式表反复解析 - 若支持多次运行，把上一次生成的
iframe.contentDocument缓存下来，仅替换内容，保留已绑定的事件监听器
eval() 和 new Function() 在线运行中必须禁用
有些简易编辑器为“支持动态执行 JS”而引入 eval()，这是严重安全隐患。真实线上环境必须：
- 完全禁止
eval、setTimeout(string)、setInterval(string)、new Function()等字符串执行类 API - 用 AST 分析或正则过滤（如
/\beval\s*\(/）在提交前拦截，不能只靠 CSP - 即便用户写了
console.log，也要重定向到自定义日志面板，避免其访问父页面console对象
真正难的不是让代码跑起来，而是让用户写的代码跑得安全、跑得稳、跑得看不出延迟——这三者之间往往互相冲突，得根据使用场景取舍。比如教学演示可以牺牲一点安全性换易用性，而技术面试平台必须堵死所有原型链污染路径。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
