html中embed标签现在很少用，因html5的video和audio标签原生支持多媒体，无需插件；2. 安全性和性能差，依赖插件易被攻击且耗资源；3. 移动设备普遍不支持插件，无法适配移动端；4. adobe已停用flash，主流浏览器不再支持。
HTML中的embed标签，简单来说，它就是用来在网页里嵌入外部内容的一个老朋友。它能把一些非HTML格式的，或者需要特定插件才能运行的文件，比如Flash动画、PDF文档，甚至是某些老旧的多媒体文件，直接显示在你的网页上。它的核心作用就是提供一个容器，让浏览器知道这里要加载一个外部的、可能需要额外处理的资源。
解决方案
使用embed标签其实挺直接的。它的基本语法是这样的：
<embed src="路径/到/你的/文件.swf" type="application/x-shockwave-flash" width="600" height="400">
这里，src属性指向你要嵌入的文件的URL，type属性则告诉浏览器这个文件的MIME类型，这对于浏览器正确识别和处理内容至关重要。width和height自然就是控制嵌入内容的尺寸了。
立即学习“前端免费学习笔记（深入）”；
你可能会发现，这标签现在用得少了。过去，它在Flash动画盛行的年代简直是标配，没有它，很多互动内容都无法在网页上展现。比如，我记得以前玩网页小游戏，或者看一些动态的网站导航，背后几乎都有embed标签的身影。它就像一个万能插座，只要有对应的插件，什么都能往里插。
为什么现代网页开发中很少直接使用 <embed> 标签了？
这个问题，其实折射出整个Web技术栈的演进。想想看，当年的网络环境和现在的简直是天壤之别。
首先，HTML5的出现彻底改变了游戏规则。我们有了更语义化、更强大的标签来处理多媒体内容，比如<video>和<audio>。它们不仅提供了原生的视频和音频播放能力，还支持多种格式，并且通常不需要额外的浏览器插件。这一下子就把embed标签在多媒体领域的地位给取代了。我个人觉得，这就像是从需要安装各种播放器的时代，直接迈入了浏览器就能搞定一切的流媒体时代，舒服多了。
其次，安全性和性能是两大考量。embed标签常常依赖于各种浏览器插件，比如Flash Player、Java Applets等。这些插件往往是安全漏洞的高发区，很多网络攻击都是通过它们进行的。而且，插件的加载和运行会消耗大量的系统资源，导致网页加载慢、卡顿。用户体验自然就差了。所以，浏览器厂商和开发者都倾向于减少对插件的依赖。
再者，移动设备的普及也是一个决定性因素。智能手机和平板电脑通常不支持这些桌面端的插件，这就意味着，如果你的网站大量依赖embed标签，那么在移动端几乎是无法正常访问的。这在“移动优先”的今天，是完全不可接受的。我记得刚开始做移动端适配的时候，最头疼的就是那些遗留的Flash内容，真是束手无策。
最后，Flash本身被淘汰也是一个重要的原因。随着Adobe停止支持Flash，各大浏览器也逐步停止了对Flash内容的渲染，这直接宣判了embed标签在Flash应用场景下的“死刑”。
在哪些特定场景下，<embed> 标签依然有其不可替代的价值？
尽管embed标签风光不再，但在某些非常特定的、小众的场景下，它依然可能被用到，或者说，不得不被用到。
最主要的一个场景就是处理一些遗留的、专有的文件格式。比如说，你可能需要在一个企业内部网里，展示一些非常老旧的CAD图纸文件，或者某些特定行业软件生成的专有格式文档。这些文件可能只提供基于特定插件的浏览器查看器，而没有现代Web标准下的替代方案。在这种情况下，embed标签就成了唯一的选择，因为它能加载那个特定的插件来渲染内容。这有点像在现代电脑上跑虚拟机来运行老软件，不是最优解，但有效。
另外，在一些特定的多媒体或交互内容归档中，如果原生的Flash文件或者其他插件内容没有被转换为现代格式，那么embed标签可能是唯一的“救命稻草”，让你能够在一个支持老旧插件的浏览器环境中（通常是特定的旧版本浏览器或虚拟机），重新查看这些内容。当然，这更多是出于历史研究或数据恢复的目的，而不是日常开发。
还有，极少数情况下，一些非标准的、高度定制化的浏览器插件（比如某些银行或政府部门使用的安全控件）可能依然通过embed标签来加载。这些往往是历史遗留问题，并且通常只在特定的操作系统和浏览器版本下才能正常工作。这真的属于“迫不得已”的范畴了。
总的来说，这些场景都非常小众，并且往往伴随着兼容性、安全性和用户体验上的妥协。它不再是构建新功能的首选，更像是一个“应急通道”。
对比 <embed>、<iframe> 和 <object> 标签，它们各自的优势与局限性是什么？
这三个标签在某种程度上都涉及“嵌入”外部内容，但它们的设计哲学和适用场景却大相径庭。
<embed> 标签：
它的优势在于语法简洁，直接指明要嵌入的资源和其MIME类型，对于那些需要特定插件才能运行的媒体类型，它曾是首选。它就像一个通用的“媒体播放器”接口。
然而，它的局限性非常明显：控制能力弱，安全性差（依赖插件），兼容性问题多，并且在HTML5时代已被更现代、更安全的标签所取代。它更像是为“外部插件内容”量身定制的。
<iframe> 标签：
<iframe> 的优势在于它能嵌入一个完整的、独立的HTML文档。你可以把它想象成在当前网页里开了一个“小窗口”，里面显示的是另一个完整的网页。这种沙盒机制（通过sandbox属性可以进一步增强）非常适合嵌入第三方内容，比如YouTube视频、Google地图、广告或者其他网站的组件。它提供了很好的内容隔离，嵌入内容通常不会直接影响到父页面，反之亦然。
它的局限性在于，由于是独立的文档，父页面与iframe内部内容的直接交互会比较复杂，需要通过JavaScript进行跨域通信。同时，如果滥用，可能会影响页面的SEO表现（搜索引擎可能会认为iframe内容不属于当前页面），并且过多的iframe也会增加页面加载负担。
<object> 标签：
<object> 标签在设计上比<embed>更通用，也更强大。它最初被设计用来嵌入各种类型的外部资源，包括图片、视频、音频、PDF、Flash、Java Applets，甚至是ActiveX控件。它提供了更丰富的属性来控制嵌入内容的行为，而且可以提供备用内容，当浏览器无法加载主要内容时，可以显示备用信息。它被认为是HTML4时代“嵌入”外部内容的推荐方式，因为它在语义上更明确，功能也更全面。
但它的局限性在于语法相对复杂，而且在很多场景下，它依然需要依赖浏览器插件来渲染某些特定类型的内容（比如Flash或PDF）。随着HTML5的普及，<object>在多媒体方面的地位也被<video>和<audio>取代。现在，它更多地出现在需要嵌入非HTML媒体，且有备用内容需求的场景，但实际使用频率也大大降低了。
我个人感觉，<iframe>是这三者中生命力最顽强的，因为它解决了“嵌入另一个网页”这个核心需求，而且与现代Web的安全和隔离理念相符。而<embed>和<object>则更像是历史的产物，随着Web技术的发展，它们的大部分功能都已经被更现代、更安全、更高效的方案所取代了。
