子组合器>在shadow dom中完全失效，因浏览器解析css时仅在同一棵树内匹配直接子元素；shadow dom是独立子树，宿主与shadow内节点无父子关系，跨boundary的选择器（如my-card>div）被解析阶段静默忽略。
子组合器 > 在 Shadow DOM 中根本不会匹配跨 boundary 的节点
浏览器解析 CSS 选择器时，> 只在**同一棵树内**找直接子元素。Shadow DOM 是独立的 DOM 子树，宿主元素（如 <my-card></my-card>）和它 shadowRoot 内的节点之间没有“父子”关系——只有“宿主-影子根”的绑定关系。所以 my-card > my-input 永远不会命中 <my-input></my-input>，哪怕它被写在 <my-card></my-card> 的 light DOM 里；而 my-card > div 在 shadow 内也只匹配 shadowRoot 直接子 <div>，不涉及 slot 分发或嵌套组件内部结构。
<h3>
<code>> 失效的典型场景和替代方案
常见误用包括：my-form > my-input 试图控制插槽内容、my-list > my-item 期望影响具名 slot 里的节点、或 my-panel > *:not(slot) 想过滤分发内容——全都不生效。
- 插槽内容（light DOM 节点）必须用
::slotted(*)控制，且仅限可继承属性（color、font-family等），>对它完全不可见 - 想选 shadow 内部的直接子，必须把规则写进 shadow root 本身，例如在
my-input的<style></style>里写:host > input - 需要跨组件通信样式意图时，改用 CSS 变量：父组件设
my-input { --input-border: 2px solid blue; }，子组件在 shadow 内用input { border: var(--input-border, 1px solid #ddd); }
为什么不用 > 而用 ::part() 或变量更可靠
::part() 是显式授权机制：只有你在 shadow 内给节点加了 part="control"，外部才能写 my-input::part(control) 定制它。> 则隐含“我假设你知道结构”，但 Web Components 的封装原则恰恰要求隐藏实现细节。一旦子组件重构内部结构（比如把 <input> 包进 <div class="wrapper">），所有依赖 <code>> 的外部样式立刻断裂。
-
::part()兼容性注意：Chrome / Edge / Safari 支持，Firefox 仍无计划支持（截至 2026 年 9 月） - 变量方案无兼容性问题，但必须确保 fallback 值可用，且声明位置正确（只能挂在宿主元素上，不能靠
:root或父容器） - 动态结构（如
my-list根据数据渲染不同数量的my-item）下，>无法表达“每个 item 的第一行”，而::part(header)或[part~="header"]可以稳定定位
真正容易被忽略的一点
开发者常以为 “> 不生效 = 浏览器 bug”，其实它是规范强制行为。Shadow DOM 的边界不是“样式穿透开关”，而是**选择器作用域的硬性终止符**。任何试图用后代选择器（ ）、子选择器（>）、相邻兄弟（+）跨越 boundary 的写法，都会在解析阶段被静默忽略——DevTools 的 Styles 面板里根本不会显示这些规则，连 warning 都没有。调试时若发现样式没出现，第一反应不该是检查拼写，而是确认选择器是否非法跨了 shadow boundary。
