<p>Shadow DOM 并非完全免疫全局样式，通配符 * 选择器会穿透边界，需通过 all: initial 显式重置继承链才能真正实现隔离；它仅对挂载在 Shadow Root 内的元素生效，子应用若操作 document.body 则样式仍会泄漏，且存在兼容性差、调试困难、事件与全局对象访问被切断等问题。</p>
为什么直接用 data- 属性无法隔离样式
很多人以为给容器加个 data-subapp="a" 就能自动阻止样式污染，其实它只是个选择器前缀载体，不参与实际隔离逻辑。真正起作用的是你是否把 CSS 规则限定在该上下文内。
常见错误现象包括：
— 子应用引入的 normalize.css 重置了全局 body 字体大小
— 父应用写了 [data-theme="dark"] .btn，却意外影响子应用里没加前缀的按钮
— 两个子应用都定义了 .modal-overlay，后者覆盖前者导致遮罩失效
-
data-属性本身不触发任何样式边界，它只在你手动写div[data-subapp="a"] .btn这类规则时才生效 - 第三方 UI 库（如 Ant Design）的
.ant-btn不会自动带上data-前缀，照样全局生效 - qiankun 的
strictStyleIsolation: true是在挂载时动态重写所有 CSS 规则，不是靠你手写的data-属性驱动的
Shadow DOM 是唯一原生样式隔离机制，但必须配 mode: "closed"
Custom Elements 注册后默认仍在 light DOM 中，外部样式照常穿透进来。只有显式调用 this.attachShadow({ mode: "closed" }) 才能启用真正的样式边界。
常见错误写法：customElements.define("my-app", class extends HTMLElement {}) —— 没在 constructor 里调用 attachShadow，等于没隔离
立即学习“前端免费学习笔记（深入）”；
-
mode: "open"允许任意脚本通过el.shadowRoot修改内部样式表或 DOM，生产环境应禁用 -
mode: "closed"下el.shadowRoot返回null，但 DevTools 可查看#shadow-root节点（需开启“Show user agent shadow DOM”） - Shadow DOM 不阻断 CSS 变量继承（如
--main-color），也不重置html、body默认样式，需显式重置
如何安全注入子应用 HTML 到 Shadow DOM
不能直接写 shadowRoot.innerHTML = htmlString，否则内联 <style> 和 <script> 会逃逸到全局作用域，造成样式污染和 XSS 风险。
- 用
DOMParser解析 HTML 字符串，提取所有<style>内容，转为CSSStyleSheet实例后通过shadowRoot.adoptedStyleSheets = [sheet]注入（Chrome 73+ / Safari 16.4+ 支持） - 剥离所有
<script src="...">标签，主应用拦截请求并代理返回带 scope 的 JS，再在沙箱中执行（必须重绑定this、window、document） -
<link rel="stylesheet">需被拦截并重写路径，否则相对 URL（如url(./img.png)）会 404 或指向主应用资源
iframe 与 Shadow DOM 的关键取舍点
iframe 提供完整 JS 执行环境隔离，但代价显著；Shadow DOM 只隔离样式，JS 仍需沙箱补足。
- iframe：独立
document、CSSOM、JS 引擎，适合嵌入不可信第三方内容；内存占用通常是 Shadow DOM 的 2.3 倍（Chrome 124 实测） - Shadow DOM：
document.querySelector、window.addEventListener、history.pushState仍会穿透影响主应用，必须配合 JS 沙箱（如 Proxy + withScope） - iOS Safari 对
iframe height: 100%渲染不稳定，常出现滚动条错位；而 Shadow DOM 在移动端兼容性更可控
真正难处理的不是样式本身，而是那些没被显式包裹进 Shadow Root 的动态节点（比如子应用运行时插入的 v-html 内容、第三方 SDK 自动挂载的浮层），它们天然落在 light DOM，绕过所有隔离机制。
