在CSS中，后代选择器ul li和子选择器ul > li都能选中列表项，但它们的匹配规则和性能表现并不相同。浏览器解析选择器时从右往左进行，理解这一点是判断快慢的关键。
浏览器如何匹配选择器
当浏览器遇到ul li时，先找到页面上所有的li元素，再逐个检查其祖先中是否存在ul。这意味着哪怕li嵌套在多层div里，只要祖辈有ul就会被选中。
而ul > li只要求li是ul的直接子元素。解析时同样从右向左，但向上只走一层，不匹配就更早退出。
简单对比
| 选择器 | 匹配范围 | 遍历深度 |
|---|---|---|
| ul li | 所有后代li | 可能很深 |
| ul > li | 直接子li | 仅一层 |
为什么子选择器通常更快
从算法角度看，ul > li在大部分情况下减少了祖先链的检查次数。如下代码结构：
<ul>
<li>直接子项</li>
<li>
<ul>
<li>嵌套子项</li>
</ul>
</li>
</ul>
使用ul li会选中三个li，使用ul > li只选中前两个直接子li。在大型文档中，后代选择器可能意外命中深层节点，增加样式计算量。
示例样式与性能观察
我们可以用一小段CSS观察差异：
/* 后代选择器：匹配所有li */
ul li {
color: blue;
}
/* 子选择器：仅匹配直接子li */
ul > li {
font-weight: bold;
}
若用JavaScript粗略统计匹配耗时，可写如下测试：
console.time('descendant');
document.querySelectorAll('ul li');
console.timeEnd('descendant');
console.time('child');
document.querySelectorAll('ul > li');
console.timeEnd('child');
在节点众多的页面里，通常child耗时更短。
实际开发建议
- 若只想修饰直接子列表，优先写
ul > li，语义清晰且性能更好。 - 需要统一深层样式时再用
ul li，但注意避免全局滥用。 - 现代浏览器引擎已做大量优化，普通页面两者差距微小，不必过度优化。
结论：从选择器机制上，ul > li比ul li更快且更精确，但在小规模项目中不必刻意纠结。