选择器的优先级
众所周知，选择器是有权重的，优先级从低到高，如下所示：
- 类型选择器（例如，h1）和伪元素（例如，
::before） - 类选择器 (例如，.example)，属性选择器（例如，
[type="radio"]）和伪类（例如，:hover） - ID 选择器（例如，#example）
-
!important 此声明将覆盖任何其他声明，不建议使用，除非以下几种情况
- 覆盖内联样式
- 覆盖优先级绝对高的选择器
选择器解析
虽然我们平常写css选择器是从左到右书写的：
根节点 .子节点 .孙节点{
}但是，这只不过是为了方便使用者书写，真正的解析顺序是反过来的，也就是从子节点搜索到根节点，原因很简单，因为查找次数将大大影响效率。一个个来说
由于css tree是树结构，如果从根节点开始，那么就是类似深度优先遍历的查找方式，一图辟千言：
如果到最后一个子节点仍然找不到的话，就是回到之前的父节点，继续查找其他的子节点，其实看起来也没毛病哈，那我们来个对比，看下css为什么选择从左到右解析。
一样的图，换了个解析方向：
很明显的差别就是，我们的判断条件提前了，先判断孙节点是否匹配，只有匹配才会继续深入，否则直接跳过，然后这就从多个多条线（深度优先遍历）变成了多个单条线的问题，有点类似于从O(n2) => O(n)的意思，大大提高了元素匹配效率
大白话解释就是：从右到左解析比从左到右解析减少了查找失败的次数和深度
还有一点就是公共样式，对于公共样式，其实就是多个相同的样式，从子节点到根节点是完全相同的，也就是一条线即可
书写高效css选择器
- 优先就是避免使用通配符匹配，这样css从右到左的解析就白搭了，莫得用处了。就和从左到右一样一样的了。
- 之前提到的选择器优先级ID选择器是最高的，但这仅仅限于单独用ID选择器，如果你和其他选择器混合使用的话，就发挥不到id选择器的唯一高效性了。为什么呢？因为从右到左解析呀，比如 #box .text，会先进行类选择器的查找，最后才是ID选择器，所以ID选择器就显的没那么重要了。
- 尽量少使用标签结束，因为这会让浏览器查找很多个子节点，然后才能确定是否匹配，比如：.box a，只要有a标签就会进行查找，但是其实我们只想给.box上的a设置样式，我们可以给个更具体的类选择器：``.box .href`，这样就能匹配更少的元素啦
- 还有就是经常说的避免选择器超过三个，比如 .div1 .div2 .div3 .p .a 就可以优化为 .div1 .a，为啥这样说的，因为查找中也有条件进行判断啊我们提供了一个子节点.a，并且是在.div1下的其实就够了，他会沿着一条线查找，知道跟节点，咱写这么多选择器只会徒增判断条件，没什么用。。
- 还有就是尽量写得具体，可以使用>操作符等等
- 选择器上能缩写的命名就尽量缩写、相同父层级的选择器合并，都可以适当减少css体积。
- 使用CSS BEM书写规范
BEM书写规范: https://github.com/Tencent/tmt-workflow/wiki/%E2%92%9B-%5B%E8%A7%84%E8%8C%83%5D--CSS-BEM-%E4%B9%A6%E5%86%99%E8%A7%84%E8%8C%83
