为什么说“真正的技术栈无关”？那是因为目前很多解决方案宣称的“技术栈无关”实现方式都不太理想，自古以来“技术栈无关”做得最好的，当属 <iframe>。然而，大部分微前端方案都不约而同地放弃了 iframe 方案，文章 Why Not Iframe 作了说明，iframe 由于良好的隔离性导致应用间的 UI 无法完美融合，比如 iframe 中的弹窗遮罩无法超越 iframe 的边界，因此我们不得不寻求其它解决方案。
“技术栈无关”作为微前端的核心价值之一，主要表现为基座应用不限制接入应用的技术栈，每个微应用都拥有独立的运行时，能够避免 DOM、CSS、JS 受到外部的影响，或者对其它应用产生影响。
DOM 隔离
很多解决方案并不关心 DOM 隔离问题，因为通常只要提供一个挂载节点，微应用便可以正常初始化。然而，微应用的 DOM 暴露在全局下，便可能被应用外的代码获取到，你无法保证其他人不搞点骚操作，或是本应用的代码对外部产生非预期的影响。当前，能做到 DOM 隔离的技术，除了古老的 iframe 外，只有 Web components。
Web components 的一个重要属性是封装——可以将标记结构、样式和行为隐藏起来，并与页面上的其他代码相隔离，保证不同的部分不会混在一起，可使代码更加干净、整洁。其中，Shadow DOM 接口是关键所在，它可以将一个隐藏的、独立的 DOM 附加到一个元素上。
Web components 可以维护一个隐藏的、独立的 Shadow DOM，不被外部检索到，从而达成 DOM 隔离的目的。
CSS 隔离
样式隔离是微前端方案解决的关键问题之一，有些方案通过合理的约定来规避 CSS 污染，常见的有 CSS Modules、BEM 规范、CSS-IN-JS 等，然而约定再好也挡不住开发者的非常规操作。而且，对于一个全新的项目，开发规范容易落实，对于现有的项目却可能带来大量的改造工作。其它方案如 qiankun 的“动态样式表”，就算只跑单应用也存在与基座应用相互影响的可能。当下，真正做到 CSS 隔离只有 iframe 与 Web components。
JS 隔离
JS 隔离是另一关键问题，常见的处理手段是创造沙箱运行 JS 代码。JS 沙箱可由 eval、with、Proxy、Function 等相互结合实现，其中，with 已经被废弃，不适合使用。而 Proxy+eval 或 Proxy+Function 避免不了原型链污染等问题，并且劫持 <script> 加载的文件，再通过 eval 方式运行，会导致 defer、async 等特性失效。更重要的是，无法通过 type="module" 使用原生 JS 模块能力。所以，目前最佳的隔离手段仍是 iframe。
新一代解决方案
通过前面的分析可见 iframe 与 Web components 才是理想的隔离技术，若是两者结合使用不就是一个绝佳的方案！新一代的微前端解决方案 <m-app> 便是通过整合同源 iframe 与 Web components 来实现技术栈无关，整体架构如下：
此外，还劫持了 iframe 环境中的 document.querySelector、 document.addEventListener 等方法，将开发者的方法调用代理到 ShadowRoot 上去，保持原有开发方式不变，降低应用接入的改造成本。
Object.defineProperties(document, {
querySelector: {
value: (...args) => ShadowRoot.querySelector(...args),
},
addEventListener: {
value: (...args) => ShadowRoot.addEventListener(...args),
},
});
而且，微应用的 Shadow DOM 与正常 DOM 的结构基本一致，整体看起来就像在用 <iframe> 一样
<m-app entry="http://example.com/path/to/entry.html"></m-app>
├─<iframe hidden>
│ ├─<meta>
ShadowRoot─│ ├─<head>─├─<title>
│ │ ├─...
├─<html>─│
│ ├─<h1>
├─<body>─├─<div>
├─...
最后，为项目求一波 star ⭐⭐⭐
