shadow dom 默认会清除宿主页面的文本选区，目前无法通过标准 api 实现完全隔离（类似 iframe 的选区独立性），唯一可靠方案是改用 iframe 封装交互元素。
shadow dom 默认会清除宿主页面的文本选区，目前无法通过标准 api 实现完全隔离（类似 iframe 的选区独立性），唯一可靠方案是改用 iframe 封装交互元素。
在 Web 开发中，Shadow DOM 常被用于构建封装良好的自定义组件，但其与宿主文档（light DOM）之间的焦点和选区行为并非完全隔离。一个典型痛点是：当用户在宿主页面中已选中文本（例如一段段落），随后点击 Shadow DOM 内部的 <input> 或 <textarea> 元素时，宿主页面的选区会立即丢失，焦点虽成功进入 shadow 内部，但用户体验断裂——这与 <iframe> 的行为形成鲜明对比。
<iframe> 天然具备选区隔离能力：其内部操作（包括聚焦、输入、选中）完全不影响父文档的 window.getSelection() 状态。而 Shadow DOM 虽提供样式与 DOM 封装，却不隔离全局选区（Selection）和焦点流（focus traversal）的副作用。根据当前（截至 Chrome 128 / Firefox 129 / Safari 17+）的规范实现与实测验证，以下方法均无法达成目标：
- ✅ event.preventDefault() 在 mousedown/focusin 中无效（选区清除发生在焦点实际转移前，不可拦截）；
- ✅ document.getSelection().removeAllRanges() 手动恢复？不可行——选区已在事件触发前被清空，且无可靠钩子捕获该时机；
- ✅ shadowRoot.delegatesFocus = false 仅影响焦点委托逻辑，不改变选区重置行为；
- ✅ getSelection().getRangeAt(0) 在 shadow focus 后已为空，无法回溯。
因此，若业务场景强依赖「宿主选区持久化」（如富文本编辑器插件、代码高亮工具栏、实时批注组件等），应主动降级为 iframe 方案：
<!-- 推荐：用 iframe 实现真正的选区隔离 --> <iframe srcdoc="<input type='text' id='editor-input' style='width:100%;padding:4px;'>" style="border:none; width:200px; height:32px;" title="isolated input" ></iframe>
✅ 优势：iframe 内的聚焦、输入、全选（Ctrl+A）等操作均不会影响宿主 window.getSelection()；
⚠️ 注意事项：需通过 postMessage 进行跨 iframe 通信；确保 srcdoc 或 src 内容受信，避免 XSS；若需样式统一，可在 iframe 内注入 CSS 或使用 document.adoptedStyleSheets（现代浏览器支持）。
总结：Shadow DOM 是优秀的封装机制，但不是安全沙箱。它不提供选区、剪贴板、焦点历史等高层 UI 状态的隔离。当需求明确指向「UI 状态零干扰」时，请优先选用 <iframe> —— 这不是妥协，而是对平台能力边界的尊重与合理架构选择。
