在富文本编辑器中直接使用<iframe>不可行，因其会被过滤、剥离或无法加载；应改用占位符+预览模式，或采用designMode iframe方案。

直接在富文本编辑器的容器里用 <iframe> 是行不通的——编辑器会过滤、剥离或转义该标签，导致嵌入失败或内容被清空。

contenteditable 容器中不能直接写 <iframe>

富文本编辑器（如基于 contenteditable 的实现）默认把 <iframe> 视为“危险 HTML”，多数会在插入时被 innerHTML 赋值、document.execCommand 或粘贴清洗逻辑中静默移除；即使保留，浏览器也不允许在 contenteditable 区域内激活 iframe 的加载行为（尤其是同源策略与 sandbox 限制叠加时）。

• Chrome / Safari 会在 contenteditable 中丢弃 <iframe> 的 src 属性，只留下空标签
• Firefox 可能保留但不渲染，控制台报错 Blocked a frame with origin "null" from accessing a cross-origin frame
• 即使强行用 insertAdjacentHTML 插入，后续光标操作（如回车、选中）极易破坏 iframe 结构

想在编辑区域“显示”外部页面？改用占位符 + 预览模式

真实可行的做法是：不嵌入 iframe，而是在编辑器中插入一个语义化占位符（比如带 data 属性的 <div>），再通过独立预览面板加载 iframe。这样既保编辑安全，又满足展示需求。

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

• 编辑时插入：<div contenteditable="false" data-embed-type="iframe" >[嵌入报表]
• 禁用该节点的编辑能力：contenteditable="false" + CSS user-select: none
• 监听编辑器焦点/内容变化，在外部容器（如右侧抽屉）检测到此类节点后，动态创建 iframe 并加载 data-src
• 点击占位符可触发预览切换，避免混淆“编辑态”和“运行态”

如果必须让 iframe 参与编辑流程，换用 <iframe> + designMode

这不是“在编辑器里嵌框架”，而是“把整个编辑器做成一个 iframe”，这是唯一能稳定承载 iframe 嵌套的上下文——因为 iframe 提供了完整的、隔离的 document 环境。

立即学习“前端免费学习笔记（深入）”；

• 主页面中创建 <iframe src="about:blank">，然后在 onload 后执行 iframe.contentDocument.designMode = "on"
• 在这个 iframe 内部，你可以自由插入 <iframe src="subpage.html">，它不会被父级编辑器干扰
• 注意：需显式设置 sandbox="allow-scripts allow-same-origin" 才能让子 iframe 加载同源资源
• 缺点明显：无法直接复用主页面的样式、字体、工具栏；父子 iframe 间通信需走 postMessage

真正卡住多数人的不是“怎么写标签”，而是没意识到 contenteditable 和 <iframe> 天然互斥——它们分属不同 DOM 生命周期与安全模型。绕过这个前提去调试属性或加 !important，只会浪费时间。