Answers:
与所有技术一样，它也有起有落。如果您使用iframe到一个经过适当开发的网站周围走走，那当然是个坏习惯。但是，有时iframe是可以接受的。
iframe的主要问题之一与书签和导航有关。如果您使用它只是将页面嵌入内容中，我认为很好。这就是iframe的用途。
但是我也看到iframe也被滥用。永远不要将其用作网站的组成部分，而应将其用作网站中的一部分内容。
通常，如果您可以在没有iframe的情况下做到这一点，那么这是一个更好的选择。我敢肯定，这里的其他人可能会提供更多信息或更多具体示例，所有这些都取决于您要解决的问题。
话虽如此，如果您仅限于HTML并且无法访问PHP或ASP.NET等后端，则有时只有iframe是您唯一的选择。
window.postMessage()进行通信，例如实现协作iframe自动调整大小。
它们不是坏习惯，它们只是另一种工具，它们增加了灵活性。
用作标准页面元素...很好，因为它们是将内容分成多个页面的简单可靠的方法。特别是对于用户生成的内容，将内部页面“沙盒化”为iframe标记不佳而不会影响主页面可能很有用。缺点是，如果您引入了多层滚动（一层用于浏览器，一层用于iframe），则用户会感到沮丧。就像adzm所说的那样，您不想将a iframe用作主要导航，而是将它们视为与视频或其他媒体文件的嵌入方式等效的文本/标记。
对于脚本化背景事件，通常在隐藏iframe和XmlHttpRequest加载当前页面的内容之间进行选择。两者的区别在于，会iframe产生页面加载，因此您可以在大多数浏览器的浏览器缓存中来回移动。请注意，XmlHttpRequest在各处使用Google的Google iframe在某些情况下也使用s来允许用户在浏览器历史记录中来回移动。
在许多情况下与他们合作之后，我真的开始认为iframe相当于goto语句的网络编程。即，通常应避免的事情。在站点内，它们可能会有所帮助。但是，对于跨网站而言，除了最简单的内容之外，对于几乎所有内容而言，它们始终是个坏主意。
考虑可能性...如果用于参数化内容，则它们已经创建了一个接口。在专业站点中，该界面需要SLA和版本管理-急于上线几乎总是被忽略。
如果用于活动内容（托管脚本的框架），则存在（不同的）跨域脚本限制。有些可以被黑客入侵，但很少会持续被入侵。而且，如果框架内容需要交互，它将很难在框架之外进行交互。
如果与许可内容一起使用，则参与站点将需要在主机之间带外移动权利信息。
因此，尽管在站点内偶尔有用，但它们非常不适合混搭。您最好查看真正的门户网站和portlet。更糟糕的是，它们是每一个网络业余爱好者的宠儿-许多技术经理已经选择他们作为解决许多问题的方法。实际上，它们创造了更多。
根据我的经验，在调用第三方代码时，iframe 的积极一面是调用一个具有Document.write();命令的javascript 。如您所知，由于解析方式（DOM解析器等），无法异步调用这些命令。例如http://sourceforge.net/projects/phpadsnew/我使用iframe来帮助加快我们的网站的速度，因为有多个调用phpadsnews的网站，并且该网站在继续进行渲染之前一直在等待响应页面的各个部分。使用iframe，我可以允许网站呈现页面的其他部分，并且仍然Document.write()异步调用phpads 的命令。防止和js锁定。
值得注意的是，无论用户的互联网连接速度或iframe的内容如何，iframe都会导致网页下载速度变小（约0.3秒），但速度明显下降。在本地对其进行测试时不会看到此内容。实际上，对添加到页面的任何元素都是如此，但是iframe似乎更糟。