首先，CSS 的读取顺序是 从右向左
举个例子
它的读取顺序是：
那么，为什么读取顺序是从右向左呢？
举个例子：
假如 DOM 结构如上图，
假设匹配规则是 .mod-nav h3 span
如果从左向右匹配，过程是：
如果从右向左匹配：
总结：这是一个树形结构，很明显，从 child 开始找 parent 比从 parent 找 child 要高效
CSS 的后代选择器本身就是一种在标准里面不那么推荐的方式。首先，对浏览器来说，ID 选择器 #xx 是最快的，其次是 class 选择器、html 元素选择器等。
假如 DOM 的结构如上图，匹配规则是 .mod-nav h3 span。
若从左向右的匹配，过程是：从 .mod-nav 开始，遍历子节点 header 和子节点 div，然后各自向子节点遍历。在右侧 div 的分支中，最后遍历到叶子节点 a ，发现不符合规则，需要回溯到 ul 节点，再遍历下一个 li-a，假如有 1000 个 li，则这 1000 次的遍历与回溯会损失很多性能。
再看看从右至左的匹配：先找到所有的最右节点 span，对于每一个 span，向上寻找节点 h3，由 h3再向上寻找 class=mod-nav 的节点，最后找到根元素 html 则结束这个分支的遍历。
很明显，两种匹配规则的性能差别很大。之所以会差别很大，是因为从右向左的匹配在第一步就筛选掉了大量的不符合条件的最右节点（叶子节点）；而从左向右的匹配规则的性能都浪费在了失败的查找上面。
当然这是比较明显情况，如果在叶子上存在多个不符合条件的 span，从右向左的规则也会走一些弯路（这时就需要优化 CSS 选择器了）。但平均来说它还是更高效，因为大多时候，一个 DOM 树中，符合匹配条件的节点（如 .mod-nav h3 span）远少于不符合条件的节点。
希望我的回答可以帮到您哦
原理：浏览器先产生一个元素集合，这个集合往往由最后一个部分的索引产生（如果没有索引就是所有元素的集合）。然后向上匹配，如果不符合上一个部分，就把元素从集合中删除，直到真个选择器都匹配完，还在集合中的元素就匹配这个选择器了。
