谈一谈浏览器解析CSS选择器的过程？
这是一道发散题，可以根据自己的理解自行解答。
在开始前，我们必须了解一个真相：为什么排版引擎解析 CSS 选择器时一定要从右往左解析？
简单的来说：浏览器从右到左进行查找的好处是为了尽早过滤掉一些无关的样式规则和元素
参考：浏览器解析css选择器的规则
- HTML 经过解析生成 DOM Tree（这个我们比较熟悉）；而在 CSS 解析完毕后，需要将解析的结果与 DOM Tree 的内容一起进行分析建立一棵 Render Tree，最终用来进行绘图。Render Tree 中的元素（WebKit 中称为「renderers」，Firefox 下为「frames」）与 DOM 元素相对应，但非一一对应：一个 DOM 元素可能会对应多个 renderer，如文本折行后，不同的「行」会成为 render tree 种不同的 renderer。也有的 DOM 元素被 Render Tree 完全无视，比如 display:none 的元素。
- 在建立 Render Tree 时（WebKit 中的「Attachment」过程），浏览器就要为每个 DOM Tree 中的元素根据 CSS 的解析结果（Style Rules）来确定生成怎样的 renderer。对于每个 DOM 元素，必须在所有 Style Rules 中找到符合的 selector 并将对应的规则进行合并。选择器的「解析」实际是在这里执行的，在遍历 DOM Tree 时，从 Style Rules 中去寻找对应的 selector。
- 因为所有样式规则可能数量很大，而且绝大多数不会匹配到当前的 DOM 元素（因为数量很大所以一般会建立规则索引树），所以有一个快速的方法来判断「这个 selector 不匹配当前元素」就是极其重要的。
- 如果正向解析，例如「div div p em」，我们首先就要检查当前元素到 html 的整条路径，找到最上层的 div，再往下找，如果遇到不匹配就必须回到最上层那个 div，往下再去匹配选择器中的第一个 div，回溯若干次才能确定匹配与否，效率很低。
- 逆向匹配则不同，如果当前的 DOM 元素是 div，而不是 selector 最后的 em，那只要一步就能排除。只有在匹配时，才会不断向上找父节点进行验证。
- 但因为匹配的情况远远低于不匹配的情况，所以逆向匹配带来的优势是巨大的。同时我们也能够看出，在选择器结尾加上「*」就大大降低了这种优势，这也就是很多优化原则提到的尽量避免在选择器末尾添加通配符的原因。
CSS优化：
不要在id选择器前使用标签名
一般写法：div#box
更好写法：#box
解释：因为id选择器是惟一的，加上div反而增加不必要的css匹配，多此一举。
使用 class 代替层级关系
一般写法：#box ul li a{}
更好写法：.box-a{}
在CSS渲染效率中，id和class的效率是基本相当的
class会在第一次载入中被缓存，在层叠中会有更好的效果，在根部元素采用id会有微妙的速度优势。
参考文档：
浏览器解析CSS原理
CSS选择器从右向左的匹配规则
