closed模式不等于隔离完成，它仅使shadowroot返回null，但无法防御dom快照、css注入、事件冒泡监听及外部样式穿透；真正隔离需组合composed: false、:host控制、slot精确开放与html严格净化。
closed 模式不能构建“不可破解”的组件——它只阻止 JavaScript 通过 shadowRoot 属性直接访问，但无法防御 DOM 快照、CSS 注入、事件冒泡监听、或 Shadow DOM 外部的样式穿透等常见绕过手段。
为什么 mode: "closed" 并不等于“隔离完成”
设置 attachShadow({ mode: "closed" }) 后，element.shadowRoot 返回 null，这是唯一生效的防护。但它不影响：
- 浏览器开发者工具仍可展开并查看 Shadow DOM 结构（Chrome/Firefox 均支持）
- 外部 CSS 仍可通过
::part()或::slotted()（若暴露了对应接口）影响内部节点 - 事件只要没被
composed: false阻断，就能从 Shadow 内部冒泡到 light DOM 并被监听 - 组件内部若使用
innerHTML、eval或未 sanitised 的属性绑定，依然存在 XSS 风险
真正起作用的隔离手段其实是组合策略
closed 模式只是第一道轻量门槛，必须配合其他机制才能提升实际隔离强度：
- 所有内部事件派发都显式指定
composed: false，避免意外泄露行为意图 - 用
:host+:host-context()控制外部样式影响范围，禁用全局* { all: initial }类重置 - 关键子节点（如输入框、按钮）添加
slot="xxx"并配合exportparts精确开放，而非暴露整个shadowRoot - 对传入的 HTML 字符串做严格 sanitisation（例如用
DOMPurify.sanitize()），不依赖 Shadow DOM 自身过滤
一个典型误用：closed 下仍试图用 querySelector 访问内部节点
下面这段代码在 closed 模式下必然失败，但很多人会忽略错误来源：
const el = document.querySelector('#my-component');
console.log(el.shadowRoot); // null —— 不是报错，而是静默返回 null
console.log(el.shadowRoot.querySelector('input')); // TypeError: Cannot read property 'querySelector' of null
更隐蔽的问题是：如果组件内部用 document.querySelector 或 document.getElementById 查找自身 Shadow 内节点，会查到 light DOM 中同名元素，导致逻辑错乱。正确做法是始终用 this.shadowRoot.querySelector(...)，并在构造函数中确认 this.shadowRoot 存在（open 模式下才非 null）。
兼容性与调试代价常被低估
closed 模式让自动化测试和调试变得更困难：
- Jest + jsdom 不支持 Shadow DOM，
closed下连模拟访问都做不到，只能退回到open模式做单元测试 - Cypress 无法用
cy.get('::shadow input')定位 closed 组件内元素，需改用属性选择器（如[data-test-id="input"]）或自定义命令注入 - React/Vue 的 devtools 插件无法展开 closed 组件结构，排查渲染问题时只能靠 console 打印或 MutationObserver 监听
除非你明确需要防止第三方脚本（如广告 SDK、分析埋点）动态读取组件结构，否则 closed 带来的维护成本远大于安全收益。多数企业级组件库（如 Shoelace、Ionic）默认用 open，靠设计约束而非封闭模式实现隔离。
