比如某个系统叫信息设备运维管理，实现设备联网、检测、统计等。
有一个名为zabbix 的程序可以完成很多此类功能。而这些东西正是客户想要的（当然，你知道，不是所有人都想要），那么从头开始开发怎么样？第二次开？
不可能的！这个决定是不可能的！客户几年前就想要它。经过协商，我们可以将客户想要的功能集成到我们的系统中。
所以这件事可以简单抽象为：需求是页面内集成三方页面（目前集成zabbix的两个页面），并且会有自动登录功能。
实现结果
温馨提示：由于动画分辨率较高，帧率设置较低，所以看起来比较卡顿。
集成前的三方系统：
您需要登录。系统中有菜单和退出功能。
多个集成的第三方系统：
无需登录，直接进入页面。没有菜单或其他无关元素。有加载功能。
方案
微前端力求以沙箱完整性、通信便利性和附加优化运行，例如预加载、缓存、允许在主机上弹出弹窗等。
iframe 的天然沙箱使用符合浏览器实现的安全规则和通信方法。所有元素（例如弹出窗口）仅限于iframe。
自动登录可以采用单点登录、模拟登录等。
微前端
可以选择qiankun、微应用、无界等前端框架。
测试使用Unbounded和Micro App实现页面集成，但是qiankun总是报错。方法没有注入（需要注入一些生命周期才能嵌入到第三方系统中）。
因此，微前端解决方案存在以下问题：
无法保证兼容性。例如，子系统的一些定位元素会转移到父系统中，这很复杂。如果出现兼容性问题，是哪个环境的问题？如果要与子系统通信，还需要跨域问题。当问题出现时，这个框架也可以做出反应。退到iframe，但是发现问题再考虑改成iframe可能已经太晚了。
iframe
为了增加集成后的用户体验，使用iframe-resizer可以让第三方页面嵌入后自然适应第三方页面的大小。你也可以和它交流。
详解通过 iframe 实现三方系统登录、通信
代码注入
比如我们可以在这里注入iframe-resizer来适配第三方系统的大小，注入jQuery实现dom操作，注入编译应用js和css的函数等。
if ((proxyRes.headers['content-type'] || ``).includes(`text/html`)) { const response=responseBuffer.toString('utf8').replace(`head`, ` 头部样式//注入样式/样式脚本//注入css 加载器functionjectCSS(css) { const style=document.createElement('style'); style.innerHTML=css; document.head.appendChild(style);加载器函数loadScript(url) { return new Promise((resolve,reject)={ var script=document.createElement('script'); script.src=url; script.onload=resolve; document.head.appendChild( script) ; }) } //注入iframe-resizer程序；${iframeResizer};${contentWindow} //配置iframe-resizer;window.iFrameResizer={ onMessage(js) { console.log('js', js) eval( js) }, onReady() { window.parentIFrame.sendMessage('onReady') console.log('onReady') } } /script `).replace(/aside([\s\S]*?)\ /aside /, '') //删除菜单返回响应}
集成到若依框架
在若易框架中，在菜单配置中，可以配置某个菜单是否为外部链接。进入第三方系统的链接后，即可嵌入第三方系统。
例如，我们在这里嵌入www.hongqiye.com/doc/mockm/页面：
它看起来就是我们想要的样子。
集成自动登录
自动登录一般采用单点登录的方式实现，一般需要第三方系统本身开启该功能。
经过查询，发现我们要集成的zabix是通过sso单点登录系统实现的，如下所示。
但我们没有这个系统，我也不想乱这个系统，因为原来的zabix可以通过表单用普通的账号和密码登录，登录后就可以得到授权。
反正我们做了一层代理，那么我们就可以在代理层自动登录了。
const data=wait fetch('http://192.168.1.253:9700/index.php', { 'headers': { 'accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image /webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7', '接受语言': 'zh-CN,zh;q=0.9,en;q=0.8,zh-TW;q=0.7', '缓存控制': 'max-age=0', '内容类型': 'application/x-www-form-urlencoded', '升级不安全请求': '1' }, 'referrerPolicy': '跨源时严格源', 'body': `request=zabbix.php%3Faction%3Ddashboard.viewname=${name}password=${password} autologin=1enter=%E7%99%BB%E5%BD%95`, '方法': 'POST', '模式': 'cors', '凭证': 'include'});const sessionid=data.headers .get(`set-cookie`)res.setHeader(`Set-Cookie`, sessionid)
这样，当通过代理访问系统时，我们就可以根据某个标识符自动获取sessionid。也可以做一个跳转页面来跳转（浏览器主机和iframe主机必须一致，否则无法设置set-cookie）：
app.use(`/auto/:base64`, async (req, res, next)={ const html=` !DOCTYPE html html head meta charset='utf-8'/script fetch('/index.php', { '标题': { '接受': 'text/html，application/xhtml+xml，application/xml；q=0.9，image/avif，image/webp，image/apng，*/*；q=0.8，application/签名交换；v=b3;q=0.7', '接受语言': 'zh-CN,zh;q=0.9', '缓存控制': 'max-age=0', '内容类型'第：章'application/x-www-form-urlencoded', '升级不安全请求': '1'}, 'referrerPolicy': '跨源时严格源', 'body': 'name=$ {data.name}password=${data.password}autologin=1enter=%E7%99%BB%E5%BD%95', '方法': 'POST', '模式': 'cors', '凭据'第：章'include' }).then(res={ window.location.href='${url}'; }) /script /head body centera href='url'${url} 加载中./a/center /body 样式html, body { width: 100% } /style /html `;
我们新建一个路由，返回一个html，html中的js请求登录所需的cookie并自动跳转。这样就可以自动登录系统。
传送页面参数
需要注意的是，在若依的系统中，配置菜单时，相同的菜单路径被视为相同的按键。选择菜单时，所有具有相同路径和不同菜单的菜单都会被选中。
另外，如果填写的路径太长，会自动在新窗口中打开。如果URL 包含点(.)，它将自动转换为斜杠。这导致我们在菜单中填写的URL看起来像这样： http://127.0.0.1/path?action=map.view 然后iframe中的src实际上接收到http://127.0.0.1/path?action=map/view。我现在不知道为什么。如果出现这样的现象，很可能是因为若一内部已经处理好了，不想去检查和修改若一的代码。因为在agent端很容易处理：
我们将所有参数转换为base64段，同时解决了若依的多层路径问题和参数特殊符号问题。
app.use(`/auto/:base64`, async (req, res, next)={ let {base64}=req.params let data=JSON.parse(Buffer.from(base64, 'base64').toString(' utf-8')) const html=` //. 到${data.url} `;
用户评论
哇，这个标题一看就很有深度。我一直对iframe有点困惑，微前端又是什么鬼？希望你能详细解释一下，让我也摆脱这种不理解的状态。
有15位网友表示赞同！
iframe不是一直被说成是性能杀手吗？现在竟然要逃离微前端，这让我有点摸不着头脑。能详细说说你的观点吗？
有7位网友表示赞同！
作为一个前端开发者，我对微前端和iframe的理解一直都很模糊。这篇博文能不能帮我理清这两者的关系呢？
有19位网友表示赞同！
逃离微前端？我不懂。但我觉得iframe用得好还是可以提升用户体验的，你说的那些问题我们团队其实并没有遇到啊。
有19位网友表示赞同！
iframe确实有点过时了，但微前端的设计初衷不就是为了更好地利用iframe的优势吗？我觉得这篇博文应该深入探讨一下。
有9位网友表示赞同！
我一直觉得iframe和微前端是两回事，没想到还有逃离微前端的说法。能不能解释一下，我有点好奇了。
有8位网友表示赞同！
微前端听起来很高级，但我在实际项目中很少用到。这篇博文提到的iframe问题，我们团队倒是有遇到过，希望能得到一些解决方案。
有10位网友表示赞同！
逃离微前端？我觉得这个标题有点误导人。微前端其实也有它的优点，不能一概而论。希望作者能给出更中肯的看法。
有17位网友表示赞同！
iframe在早期确实是个好东西，但现在看来它确实有点过时了。不过，微前端是不是也该考虑一下其他解决方案呢？
有13位网友表示赞同！
我尝试过使用iframe和微前端，但感觉效果并不理想。这篇博文提到的逃离微前端，或许正是我一直在寻找的出路。
有5位网友表示赞同！
逃离微前端，听起来像是一场技术革命。我期待看到更多的实践案例，看看如何在实际项目中实现这一转变。
有7位网友表示赞同！
我对iframe的理解还不够深入，这篇博文如果能从基础讲起，那就太好了。希望能帮到我这个新手。
有14位网友表示赞同！
微前端和iframe的结合，听起来像是完美的解决方案。但是，现实总是残酷的，希望这篇博文能揭示一些隐藏的问题。
有20位网友表示赞同！
我一直认为iframe是解决跨域问题的好方法，但微前端的出现似乎让这一切都变得复杂起来。这篇博文能不能帮我理清头绪？
有18位网友表示赞同！
逃离微前端，这让我想起了那句“技术无边界”。希望这篇博文能让我们看到更多的可能性。
有13位网友表示赞同！
微前端和iframe，两个听起来都很高大上的概念。但实际操作起来，却让人头疼不已。希望这篇博文能给出一些实用的建议。
有17位网友表示赞同！
作为一个前端开发者，我对微前端和iframe的理解一直处于半桶水的状态。这篇博文能否帮我解决这个难题呢？
有7位网友表示赞同！
逃离微前端，这让我想起了自己曾经的一次技术转型。希望这篇博文能让我在新的道路上找到方向。
有19位网友表示赞同！
iframe和微前端，这两个概念对我来说都是新玩意。这篇博文能不能从入门级开始，让我一步步学习呢？
有12位网友表示赞同！