iframe是现代唯一推荐的嵌入方案，因持续获浏览器维护、支持sandbox/csp等安全机制；embed已基本弃用，仅pdf在严格条件下勉强可用。
iframe 和 embed 都能嵌入外部内容，但它们的定位、能力、安全机制和浏览器支持现状完全不同——iframe 是现代 Web 的标准嵌入容器，而 embed 已基本退场，仅在极少数 PDF 或旧系统场景中“勉强可用”。
iframe 是唯一被主流浏览器持续维护的嵌入方案
iframe 的核心价值不是“能塞东西”，而是提供一个**隔离的、可控的、可通信的 HTML 执行上下文**。它支持 sandbox、referrerpolicy、loading="lazy"、CSP 策略，还能通过 postMessage 与父页双向通信。现代第三方组件（如图表编辑器、支付弹窗、文档预览）几乎全部基于封装好的 HTML 页面 + iframe 实现。
- 必须显式设置
sandbox="allow-scripts allow-same-origin"才能让子页 JS 运行；漏掉allow-scripts会导致白屏且无报错 -
src写相对路径（如"chart.html"）时，在/admin/report页面下会请求/admin/chart.html，应统一用根路径"/chart.html" - 跨域时禁止直接访问
iframe.contentWindow.document，必须改用postMessage+message事件监听 - Chrome 95+ 对非 PDF 的
embed会静默失败，但iframe加载同源 HTML 页面始终可靠
embed 只剩 PDF 场景下“凑合能用”，其他基本失效
embed 没有 DOM 子树概念，不触发 load 事件，无法监听加载状态，也不支持 loading="lazy"。它依赖浏览器插件机制，而 Flash、Java、ActiveX 全部被禁用，目前唯一常见用途是内建 PDF 阅读器——但也仅当服务端返回 Content-Type: application/pdf 时才生效。
- 写
<embed src="doc.pdf#page=3"></embed>可跳转指定页，但移动端渲染可能卡顿或缩放异常 - 若 PDF 文件返回的是
text/plain或未设 MIME 类型，Chrome 会直接下载而非内嵌 - 无法用 JS 获取其内部任何状态（比如当前页码、是否加载完成），也控制不了滚动位置
- 在 Safari 中，
embed加载 PDF 后可能阻塞主线程，导致页面响应变慢
object 标签比 embed 更通用，但依然不是首选
object 是规范里最通用的嵌入容器，理论上能 fallback 到备用内容（如 <p>您的浏览器不支持 PDF</p>），也支持 type 属性校验 MIME 类型。但它同样缺乏 iframe 级别的安全控制和通信能力，且在实际项目中兼容性更难把握。
- 某些 Android WebView 对
object的 PDF 渲染支持不一致，有的显示空白，有的强制下载 - 即使设置了
data和type，若服务端未返回正确Content-Type，仍可能降级为下载 - 没有
sandbox属性，无法限制脚本执行或表单提交行为，安全性弱于iframe - 不能像
iframe那样用contentWindow获取上下文，也无法可靠监听加载完成
真正要嵌入可交互内容时，别纠结 embed 或 object 的属性细节——先确认：那个内容能不能做成一个独立的、同源的 HTML 页面？如果能，就用 iframe；如果不能（比如纯静态 PDF），再考虑 embed，并准备好 fallback 下载链接。最容易被忽略的一点是：iframe 的 sandbox 不是“开箱即用”，而是“不开就不动”，连 console.log 都不会执行。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
