是，但仅当宿主有tabindex且shadow内存在首个可聚焦元素时生效；它仅改变鼠标点击宿主时的焦点委托行为，不干预tab键顺序或自动聚焦。
delegatesFocus 设为 true 后，焦点真的会自动跳进 Shadow 内部吗
会，但只在满足特定条件时生效。它不是“自动聚焦”，而是改变焦点委托行为：当用户点击 Shadow Host 元素（比如一个 <my-button></my-button>）时，若该元素本身不可聚焦（tabindex="-1" 或没设 tabindex），浏览器会把焦点委托给 Shadow Root 内第一个可聚焦子元素（如 <button></button>、<input>、带 tabindex="0" 的 <div>）。
<p>常见错误是以为设了 <code>delegatesFocus={true} 就能解决所有键盘导航问题——其实它不触发 focus()，也不影响 Tab 键顺序本身，只影响“鼠标点击宿主元素”这一种入口场景。
- 宿主元素必须有
tabindex（哪怕为-1），否则点击不会触发委托逻辑 - Shadow 内部第一个可聚焦元素必须真实存在且未被
disabled或hidden - 若内部多个元素都可聚焦，只委托给 DOM 顺序中第一个（不是视觉顺序或
tabindex值最小的那个） - Chrome / Firefox / Safari 当前（2026 年中）均支持，但 Safari 对
delegatesFocus在mode: "closed"下的行为仍不稳定，建议仅用于open模式
为什么在多层 Shadow DOM 嵌套中 delegatesFocus 容易失效
Shadow DOM 的委托焦点是单跳的：父 Shadow Root 的 delegatesFocus 只控制“从宿主到自身 Shadow 内部”的委托，不穿透到子组件的 Shadow Root 中。也就是说，<outer></outer> → <inner></inner> → <button></button> 这条链里，即使 <outer></outer> 和 <inner></inner> 都设了 delegatesFocus={true}，点击 <outer></outer> 也只会委托到 <inner></inner> 元素本身（如果它可聚焦），而不会继续深入到 <inner></inner> 的 Shadow 内部。
要实现真正的“穿透式焦点委托”，必须手动补全中间环节：
-
<inner></inner>必须设tabindex="0"（使其成为可聚焦宿主） -
<inner></inner>的 Shadow Root 中需有一个可聚焦元素（如<slot></slot>后的内容或内部<button></button>） - 必要时，在
<inner></inner>的focusin事件中主动调用shadowRoot.querySelector('button').focus()，完成二次跳转 - 避免在
focusin中反复调用focus()，否则可能触发无限循环（尤其在 Safari 中）
delegatesFocus 与 focus-within 样式配合时的优先级陷阱
:focus-within 伪类在 Shadow DOM 中能正常工作，但它依赖的是“当前元素或其后代获得焦点”这个事实，而 delegatesFocus 不会改变宿主元素自身的聚焦状态——它只是把焦点“送进去”。所以：<my-input></my-input> 宿主本身不会变成 :focus，但它的 Shadow Root 内部元素会；此时 <my-input>:focus-within</my-input> 依然匹配成功。
统一LLM网关 - 一个API对接70+AI模型，使用单一API密钥即可调用GPT、Claude、Gemini、Qwen、Deepseek、Grok等主流模型。
容易踩坑的是嵌套结构里的样式覆盖：
- 若
<my-input></my-input>内部有<div class="wrapper"><input></div>，且你写了.wrapper:focus-within { outline: 2px solid blue; }，那这个样式只在<input>获焦时生效，跟delegatesFocus无关 - 但如果你同时写了
my-input:focus-within { border: 2px solid green; }，它会在点击宿主后立即生效（因为内部 input 获焦 → 触发 :focus-within） - 注意权重：外部 CSS 中写
my-input:focus-within和 Shadow 内部写:host(:focus-within)是等价的，但后者更容易被内部样式覆盖
真正影响键盘导航体验的，往往不是 delegatesFocus 本身
很多团队花时间调 delegatesFocus，结果发现 Tab 键路径还是乱——根本原因常在于没有统一管理 tabindex 序列，或忽略了 Shadow 内部元素的 disabled / hidden 状态变化。
实操建议：
- 用
document.activeElement+shadowRoot.elementFromPoint()组合做调试，确认焦点是否真进了 Shadow 内部 - 不要依赖
delegatesFocus来修复 Tab 顺序；它只解决“点击即聚焦”这一个动作，Tab 流必须靠显式tabindex控制 - 复杂表单组件中，建议在 Shadow Root 初始化时遍历所有可聚焦节点，按 DOM 顺序缓存为数组，再用
keydown监听Tab手动接管跳转逻辑 -
delegatesFocus对屏幕阅读器（SR）的支持有限；若需完整 a11y，仍需配aria-labelledby、role和显式focus()调用
最常被忽略的一点：delegatesFocus 不会阻止焦点离开 Shadow DOM。一旦用户按 Tab 离开内部最后一个可聚焦元素，焦点就回到下一个外部可聚焦节点——这个边界行为无法用该参数控制，只能靠外围逻辑拦截或重定向。
