先记住这个答案
CSS 优先级体系把选择器分成三列。从左到右分别是 ID、类（含属性和伪类）、元素（含伪元素）。比较两个选择器时先看最左边的 ID 列，数字大的直接赢，不用再看后面的列。只有 ID 列相等才比类列，类列也相等才比元素列。这就是为什么一个 #nav 可以赢过任意多个 .class——因为 (1, 0, 0) 的 ID 列是 1，而 (0, n, 0) 的 ID 列是 0，比较到 ID 列就结束了。
- ID 列高于类列，不看数量
#id计入第一列，[id=x]计入第二列- 三列之间不存在进位
- 实际项目尽量少用
#id选择器
一个 ID 赢过一排类
日常开发中经常遇到这样的场景：给一个元素写了一堆类选择器来描述样式，结果被另一条只用了 ID 选择器的规则覆盖。
/* 优先级 (1, 0, 0)，只有一个 #id */
#nav {
color: red;
}
/* 优先级 (0, 4, 0)，四个类叠加 */
.header .main .list .link {
color: blue;
}
/* 最终 #nav 匹配到的元素显示红色 */这两条规则如果作用在同一个元素上，红色赢。因为比较只看 ID 列：#nav 是 1，四个类加起来在 ID 列仍然是 0。就算把类叠加到 100 个，在 ID 列为 0 的情况下永远输给 ID 列为 1 的规则。
很多人以为优先级是一个十进制数，比如把 (0, 4, 0) 理解成 40，觉得够大了就能赢。实际上三列是独立比较的，不存在进位。这和 IP 地址每段独立类似，0.255.255 永远小于 1.0.0。
实际项目里怎么控制 ID 优先级
正因为 ID 的优先级太高，在实际项目中反而应该少用 #id 选择器。一旦用了，后续想覆盖就只能加 !important 或者写更长的 ID 选择器链，维护成本直线上升。
大多数 CSS 方法论（BEM、OOCSS、Tailwind）都建议只用类选择器。需要唯一标识元素时用 id 属性做锚点或 JavaScript 选取，但在 CSS 样式规则中用 .class 代替 #id。
如果已经有一条 #id 规则想低成本覆盖，有几个办法。把覆盖声明也写成 #id 选择器并放在后面，来源顺序会让后面的赢。或者用 #id.class 把优先级提到 (1, 1, 0)。最后的兜底是 !important，但这会开启另一场优先级军备竞赛，尽量避免。
另一种思路是用 @layer 控制层级。把第三方库的样式包进先声明的层，自己的业务样式放在后声明的层或不入层，这样即使第三方库内部用了 #id，层叠层的顺序也会让业务样式优先。
容易答错的地方
- 把
[id=nav]当 ID 选择器 [id=nav]匹配的元素和#nav一样，但[id=nav]是属性选择器，优先级是(0, 1, 0)而不是(1, 0, 0)。利用这个差异，可以通过[id=nav]引用 ID 又不抬高优先级。- 以为加
!important就等于提高优先级 !important不是在三列里加了什么。它把声明提升到一个更高的层叠层级：所有!important声明先内部按优先级排名，再整体赢过所有普通声明。两个都带!important的声明还是要比三列优先级。
面试官还会怎么问？
内联样式在三列里排第几？
内联样式不在选择器三列里，它是写在 HTML 的 style 属性上的，优先级天然高于任何选择器规则。想覆盖内联样式，要么用 !important，要么用 JavaScript 直接改 style。
怎么在不提高优先级的前提下覆盖样式？
用 @layer 把基础样式放进先声明的层，业务覆盖样式放在后声明的层或直接不入层。层的声明顺序优先于选择器优先级。另一种做法是用 :where() 包裹选择器，它的优先级固定为零。
:not() 和 :is() 会影响 ID 列的优先级吗？
会。:not(#x) 和 :is(#x) 的优先级取参数中最高那个选择器的权重，如果参数里有 #id，就在 ID 列加 1。:where() 是例外，不管参数是什么，整体优先级都是零。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。