不存在“硬件级硬隔离”，浏览器仅通过iframe实现进程/上下文级隔离，shadow dom需用adoptedstylesheets注入样式、剥离脚本并重绑定上下文，且mode必须在constructor中设为"closed"。
不存在“硬件级硬隔离”——浏览器没有提供任何硬件层面的HTML渲染隔离能力，所有所谓“硬隔离”都是软件抽象层的工程实现，最接近的原生方案只有 iframe，但它也不是硬件级，只是进程/上下文级隔离。
为什么“硬件级硬隔离”是误导性说法
浏览器运行在操作系统用户态，不直接操控CPU或内存硬件；所谓“硬”只体现在 iframe 的独立渲染进程（Chrome 中每个 iframe 可能分配独立 renderer 进程）、独立 JS 执行上下文、独立 DOM 树和样式作用域。但这仍受制于同源策略、跨进程通信开销、GPU 合成层限制等软件约束。
- 即使启用
iframe，若子应用与主应用同源，window.parent仍可被访问，隔离不彻底 - 移动端 iOS Safari 对
iframe的 height: 100% 渲染不稳定，常导致滚动错位——这不是硬件问题，而是 WebKit 渲染管线缺陷 - WebAssembly 模块也无法绕过 JS 上下文污染，
document.body修改依然生效
shadowRoot.innerHTML = htmlString 会逃逸样式和脚本
这是微前端中最常踩的坑：把含 <style></style> 或 <script></script> 的 HTML 字符串直接赋给 shadowRoot.innerHTML，会导致：
-
<style>.btn{color:red}</style>内容漏出到全局，污染整个页面 -
<script>document.body.classList.add('dark')</script>在全局上下文执行，不是 shadow 内部 - 控制台报错
Failed to execute 'querySelector' on 'Document': The provided selector is empty（因脚本执行时 DOM 尚未挂载）
正确做法是用 DOMParser 解析后分治处理：style 转为 CSSStyleSheet 实例，再通过 shadowRoot.adoptedStyleSheets = [sheet] 注入；script 必须剥离，在沙箱中重绑定 this/window/document 后执行。
mode: "closed" 必须在 constructor() 中调用
延迟到 connectedCallback 或更晚调用 this.attachShadow({ mode: "closed" })，等于 DOM 已渲染、CSS 已计算完毕，污染不可逆。
-
mode: "open"允许外部脚本通过el.shadowRoot直接篡改内部节点或样式表，生产环境必须禁用 -
mode: "closed"下el.shadowRoot返回null，但 DevTools 可查看#shadow-root（需开启“Show user agent shadow DOM”） - CI/CD 流水线应强制校验：所有
attachShadow调用必须含{ mode: "closed" }，否则阻断构建
adoptedStyleSheets 不支持 @import 和相对路径
这是实际落地中最容易忽略的兼容性断点：
-
@import规则在CSSStyleSheet实例中被忽略，必须提前内联或预加载 -
url(./icon.png)中的./会解析为主应用根路径，而非子应用资源目录，需运行时重写路径 - CSS 变量继承链（如
--main-color）默认穿透 Shadow DOM，需显式用all: initial或inherit控制
真正难的不是写对一行 attachShadow，而是让子应用的 CSS 资源路径、变量作用域、字体继承、伪元素样式全部在 Shadow DOM 内自洽——这需要构建时预处理 + 运行时代理 + DevTools 级别调试探针三者协同，缺一不可。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
