1. CSS 选择器的匹配原理与性能维度
1.1 选择器匹配的基本流程
匹配成本来自于选择器的复杂度与 DOM 的规模，浏览器渲染引擎需要把 CSS 选择器转换为可执行的匹配逻辑，并在样式计算阶段对 DOM 树执行匹配。简单选择器往往更快，复杂组合会带来成倍的对比成本。
在现代引擎中，选择器被分解为若干“选取器”并组合成一个匹配计划，越是嵌套和后代的条件，候选元素集合越大，花费也越多。
1.2 影响匹配成本的因素
除了选择器本身的结构，DOM 的规模、元素的可见性（如 display:none 的元素不参与渲染）、以及样式表的数量都会影响性能，因此在大型页面上，选择器设计往往会显著影响样式计算的时间。
在一个典型的页面中，对比同等数量的元素，简单的层级选择器通常比复杂的组合或伪类选择器更高效，这是因为引擎在实现时对简单路径做了优化。
1.3 具体案例：简单选择器与复合选择器的对比
对于简单的单一标签选择器，如 ul、li，浏览器能快速定位到目标集合，而对于组合选择器如 ul .item、ul > li、ul li.active 等，需要更多的匹配步骤。
/* 示例：简单选择器与复合选择器的对比 */
ul li { color: #333; }
ul > li { color: #333; }
在现实的样式表中，组合选择器的命中成本通常高于简单后代选择行为，尤其是在大量嵌套和深层结构的页面中更为明显。
2. ul li 与 ul>li 的语义比较与匹配规则
2.1 子元素选择器的含义与实现
ul > li 指定的是 ul 的直接子元素 li，这是一种“父子”关系的限定匹配，不会匹配在 ul 内部的孙子节点，确保样式仅作用于直接子项。
而 ul li 是一种后代选择器，它会匹配位于 ul 内任意层级的 li，当 ul 内存在嵌套的子列表时，这种匹配会覆盖更多元素。
2.2 实战对比：在常见的菜单结构中的表现
对于没有嵌套的简单列表结构，ul li 与 ul > li 的命中数量通常相近，差异主要来自 是否存在嵌套的 ul，若存在嵌套，后代选择器的覆盖面更大。
在带有多级菜单的场景中，ul li 可能选中所有级别的 li，从而影响样式的生效粒度，而 ul > li 只作用于当前 ul 的直接子项，颗粒度更小。
2.3 相关的匹配成本对比代码示例
下面展示两种选择器的简单对比代码片段，用于理解语义差异与潜在的匹配成本：直接观测两者的命中集合差异十分直观。
/***** CSS 示例，演示两种选择器的作用 *****/
ul li { background: lightblue; }
ul > li { background: lightgreen; }在包含多级嵌套的未结构化列表时，后代选择器的命中范围要大于直接子元素选择器，这将对样式计算的工作量产生影响。
3. 实测数据与实际渲染中的性能影响
3.1 浏览器的渲染路径与匹配阶段的开销
渲染管线将样式计算分成风格表解析、选择器匹配、布局与绘制等阶段，这其中的选择器匹配是最常见的瓶颈之一，尤其在存在大量规则和复杂选择器时。
在引擎内部，匹配过程通常采用自底向上的遍历和多路分解策略，后代选择会导致较多的候选元素遍历，而直接子选择器的限制减小了候选集。
3.2 大规模 DOM 与重复选择的影响
当 DOM 数量达到数万甚至更多时，选择器对比的影响会被放大，ul li 的后代匹配在嵌套结构中更容易触发重复检查，而 ul > li 的匹配路径更短，因此在某些场景下表现更稳定。
对于大量重复的样式规则，简化选择器并限制到直接子项往往能带来可观的性能收益，不过实际效果受浏览器版本与机器性能影响。
3.3 代码示例：微基准对比
下面提供一个简单的微基准，用于对比两种选择器在同一文档中的执行时间，请在浏览器控制台执行并观察结果。该基准仅用于说明趋势，实际环境会有波动。
function measure(sel){const t0 = performance.now();document.querySelectorAll(sel);const t1 = performance.now();return t1 - t0;
}
const t1 = measure('ul li');
console.log('ul li 选取耗时（毫秒）:', t1);
const t2 = measure('ul > li');
console.log('ul > li 选取耗时（毫秒）:', t2);
在多数现代浏览器的典型页面中，两者的时间差异通常较小，且受实际 DOM 布局的影响显著，尤其当文档中没有大量嵌套的 ul 时，差异更为接近。
