Shadow DOM不隔离JavaScript执行环境，仅隔离DOM和CSS；脚本仍全局执行，需靠ES模块、闭包和自定义元素类封装逻辑，iframe沙箱才是真正的JS执行隔离方案。
Shadow DOM本身不隔离JavaScript执行环境
Shadow DOM只隔离DOM树和CSS作用域，script标签在Shadow Root里仍会全局执行，变量、函数、事件监听器都逃不出全局作用域。你以为把<script>console.log('in shadow')</script>塞进shadowRoot.appendChild()就能隔开逻辑？不行——它和页面其他脚本共享同一个window，照样污染全局命名空间、触发重复绑定、覆盖同名函数。
常见错误现象：Uncaught TypeError: myUtil is not a function（因为另一个组件先删了window.myUtil），或click事件被多个Shadow Root里的监听器反复响应。
- Shadow DOM不是沙箱，它不创建新的JavaScript执行上下文
-
eval()、Function()构造函数、内联onclick属性，全都在全局作用域运行 - 即使用了
attachShadow({mode: 'closed'})，也无法阻止脚本访问window或document
真正能隔离JS逻辑的只有模块作用域和手动封装
想让组件逻辑互不干扰，得靠ES模块边界+闭包+显式API暴露，而不是依赖Shadow DOM。把逻辑写在class里、用export导出最小接口、用import按需加载，才是正解。
使用场景：自定义元素中，把渲染逻辑和业务逻辑拆开——Shadow DOM负责结构与样式隔离，class实例负责状态与行为封装。
立即学习“Java免费学习笔记（深入）”；
- 所有私有变量用
#privateField语法（或闭包模拟），避免从外部篡改 - 事件监听统一绑定在组件实例上，用
this.addEventListener()而非document.addEventListener() - 避免在
connectedCallback里直接写setTimeout(() => { /* 一堆逻辑 */ }, 100)——闭包外泄容易引发内存泄漏 - 如果必须动态执行字符串代码，用
new Function('return ' + code)()比eval稍安全，但仍不推荐
示例：一个计数器组件，其increment方法不会被其他组件意外调用，是因为它没挂到window，也没暴露this引用：
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
class CounterElement extends HTMLElement {
#count = 0;
constructor() {
super();
const shadow = this.attachShadow({mode: 'open'});
shadow.innerHTML = `<button>Count: <span>${this.#count}</span></button>`;
shadow.querySelector('button').addEventListener('click', () => this.#increment());
}
#increment() { this.#count++; this.shadowRoot.querySelector('span').textContent = this.#count; }
}第三方脚本注入时尤其危险
如果组件需要加载外部JS（比如分析SDK、广告脚本），直接appendChild一个<script src="...">到Shadow Root，该脚本依然会运行在主文档上下文中，可能读取或修改其他组件的状态，甚至触发CSP报错（因script-src通常不允许多个nonce）。
性能影响：多个组件各自加载同一份lodash.js，会重复下载、解析、执行，浪费带宽和CPU。
- 绝对不要用
shadowRoot.innerHTML += '<script src="..."></script>' - 如需加载外部逻辑，优先用
import('./analytics.js')动态导入，并确保模块只初始化一次（加if (!window.__ANALYTICS_INIT)守卫） - 若必须内联第三方代码，用
blob:URL配合iframe sandbox做轻量级隔离——但要注意跨域限制和通信成本
浏览器原生沙箱能力目前仅限于iframe
想真正隔离JS执行，目前唯一可靠方案是<iframe sandbox="allow-scripts">。Shadow DOM没有sandbox属性，也不能阻止postMessage通信或CustomEvent冒泡到light DOM。
兼容性影响：IE完全不支持Shadow DOM；Safari对closed mode的支持有限；而iframe沙箱在所有现代浏览器中行为一致。
- Shadow DOM + iframe组合可用：把核心交互逻辑放进
iframe，用srcdoc注入HTML+JS，再通过postMessage与宿主通信 - 注意
iframe的contentWindow在srcdoc模式下可访问，但src="about:blank"则受同源策略更严限制 - 不要试图用
Object.freeze(window)或Proxy拦截全局对象——既不可靠，又拖慢性能
复杂点在于权衡：Shadow DOM解决样式和DOM冲突，模块系统解决JS作用域，iframe解决执行环境隔离——三者定位不同，混用时容易高估Shadow DOM的能力。最容易被忽略的是，开发者常把“结构隔离”误认为“逻辑隔离”，结果调试时发现状态被意外重置，却花半天查Shadow Root边界，其实问题出在共享的localStorage或未清理的定时器上。
