启用delegatesFocus是保障微前端嵌套子应用键盘Tab导航连续性的关键——它使焦点穿透多层Shadow DOM落到内层可聚焦元素，避免卡顿、语义丢失及WCAG合规问题。
在微前端子应用嵌套场景中（例如基座 → 子应用 A → 子应用 C），启用 delegatesFocus 是保障键盘用户连续 Tab 导航的关键手段——它让焦点能自然穿透多层 Shadow DOM 边界，落到最内层可聚焦元素上，避免卡在宿主容器或空白区域。
为什么嵌套子应用必须显式启用 delegatesFocus
微前端中，子应用常通过自定义元素（如 <micro-app name="search">）挂载，内部通常用 attachShadow 封装。若未开启 delegatesFocus：
- 用户按 Tab 进入该自定义元素时，焦点停在宿主标签本身，而非内部的
<input>或<button>； - 嵌套更深的子应用（如子应用 B 内的子应用 C）会进一步中断焦点流，导致键盘用户无法抵达实际控件；
- 屏幕阅读器仅播报宿主元素名（如 “micro-app”），无法识别其功能语义，违反 WCAG 2.1 键盘可操作与信息可感知原则。
正确配置 delegatesFocus 的三步落地法
该属性必须在创建 shadow root 时声明，且需配合内部结构与状态同步：
PigX UI 前端开发
下载
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- 在子应用封装的自定义元素构造函数中，调用
this.attachShadow({ mode: 'open', delegatesFocus: true })； - 确保 shadow 内存在且仅有一个默认可聚焦元素：优先使用原生
<input>、<button>，或为首个交互元素设置tabindex="0"； - 若子应用自身也包含嵌套子组件（如搜索框内含清空按钮），这些子组件的 shadow root 同样需启用
delegatesFocus，形成逐层委托链。
聚焦状态需跨层级同步，不能只靠 delegatesFocus
delegatesFocus 解决“能否进入”，但不解决“是否可见”。用户需要视觉反馈确认当前焦点位置：
立即学习“前端免费学习笔记（深入）”；
- 在 shadow 内部
<input>上监听focus和blur，触发时通过this.toggleAttribute('focused', true/false)更新宿主元素状态； - 在宿主样式中使用
:host([focused])设置轮廓、阴影或边框高亮； - 若子应用由框架（如 React/Vue）渲染，需确保其根节点是自定义元素，并在生命周期中完成上述监听绑定，而非依赖框架自身的 focus 处理逻辑。
避开常见陷阱：嵌套场景下的典型误操作
微前端嵌套放大了 Shadow DOM 的边界效应，以下做法会直接破坏焦点连贯性：
- 在任意一层子应用中关闭
delegatesFocus，并试图用shadowRoot.querySelector('input').focus()手动聚焦——这会跳过浏览器原生 Tab 顺序，导致焦点“丢失”或重复聚焦； - 多个嵌套 shadow 中同时设置
autofocus，引发委托目标不确定，尤其在动态加载子应用时易出现焦点错位； - 依赖
focusin事件在宿主监听聚焦——该事件不穿透 shadow boundary，必须监听内部元素事件并主动同步。
