delegatesfocus不适用于微前端子应用嵌套场景，它仅在单个shadow dom内部生效，用于点击宿主时自动聚焦内部首个可聚焦元素，无法解决跨iframe或跨沙箱的焦点流转问题。
delegatesFocus 本身不适用于微前端子应用嵌套场景，它无法优化跨应用边界的焦点导航路径。
这个属性只在单个 Shadow DOM 内部生效，作用是控制：当用户点击 Shadow DOM 宿主元素（比如一个自定义 <my-input></my-input> 标签）时，焦点是否自动“委托”到其内部第一个可聚焦子元素（如 <input>）。它解决的是组件封装层内的焦点入口问题，而非跨运行时、跨沙箱、跨文档的焦点流转。
微前端中常见的子应用嵌套（例如主应用通过 iframe 或 web component + 动态挂载 加载子应用），面临的是更底层的隔离与通信问题：
若子应用运行在 iframe 中：
iframe 天然拥有独立的window、document、focus栈和Selection状态。此时焦点在 iframe 内操作完全不影响主应用，也无需delegatesFocus—— 它根本不起作用（iframe 不支持该属性）。-
若子应用以 Shadow DOM 方式挂载（非常规且不推荐）：
即强行把整个子应用的 HTML 插入某个元素的shadowRoot。这种做法存在严重限制：- 子应用内动态创建的
<script></script>、<link>、<style></style>不会执行或生效； -
document.querySelector、window.addEventListener('load')等全局 API 行为异常； -
delegatesFocus: true最多让点击宿主容器时跳进 shadow 内第一个<input>，但无法接管子应用自身的 Tab 键序、路由切换焦点、模态框焦点陷阱等复杂逻辑； - 更关键的是：Shadow DOM 不隔离 JavaScript 执行环境或事件代理链，子应用仍能访问并污染主应用的
window，违背微前端沙箱核心目标。
- 子应用内动态创建的
因此，真正影响微前端焦点导航路径的关键点不在 delegatesFocus，而在以下三处：
沙箱机制选型
使用proxy沙箱（如 qiankun 的 legacy 模式）或Snapshot沙箱时，子应用对document、focus()、addEventListener('focusin')的调用会被劫持并重定向到其虚拟document，从而避免焦点操作意外影响主应用。需确保沙箱正确拦截focus、blur、focusin、focusout及tabindex相关读写。焦点恢复协议
主应用应在子应用 mount 前缓存document.activeElement，并在子应用 unmount 后主动调用.focus({ preventScroll: true })恢复原焦点。子应用内部也应遵循 ARIA Authoring Practices，在模态框关闭、路由离开时手动归还焦点。Tab 键流统一治理
主应用可监听全局keydown事件捕获Tab键，结合composedPath()判断当前焦点是否在子应用容器内；若子应用未响应或失焦，由主应用接管 Tab 导航逻辑（例如跳转到下一个微应用入口区），避免焦点“卡死”。
简言之：delegatesFocus 是 Web Components 组件级封装工具，不是微前端架构层的焦点调度器。
想让微前端焦点路径清晰可控，重点应放在沙箱完整性、生命周期钩子中的焦点快照/恢复、以及跨边界 Tab 流的显式协调上。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
