网页样式的最终呈现，并不是某一条规则单独说了算。浏览器会把外部样式表、<style>块、内联 style 属性以及浏览器默认样式全部放进同一个层叠上下文里，再按照来源、特异性、出现的先后顺序决定谁生效。理解引入方式对覆盖的影响，能够减少很多不必要的 !important 堆叠。
引入方式如何影响层叠顺序
从CSS来源看，外部 <link> 引入的样式、页面中的 <style> 块，以及元素上的 style 属性，都属于作者样式。它们之间的覆盖关系，第一步先看来源权重，第二步才比较特异性。单就作者来源而言，三种引入方式在同等特异性下，最终顺序由它们在文档中的出现位置决定。出现越靠后的规则，越有机会覆盖前面的规则。
这里有一个非常典型的场景：同一个 .box 类在外部样式表里设置为蓝色，在页面 <style> 块里设置为红色，那么红色会生效，因为 <style> 块如果位于 <link> 标签之后，后定义的规则胜出。即便两个规则选择器完全一致，也不看哪个文件更大或者更具体，只看位置。
<!DOCTYPE html>
<html>
<head>
<link rel="stylesheet" href="common.css">
<style>
.box { color: red; }
</style>
</head>
<body>
<div class="box">这段文字会显示为红色</div>
</body>
</html>
如果样式表中还有 @import 规则，情况会稍微复杂一些。 @import 必须出现在样式表或 <style> 块的最前面，导入的规则会被插入到 @import 所在的位置。也就是说，如果 @import 写在 <style> 块的顶部，那么导入的外部样式规则会先进入层叠，写在 @import 后面的本地规则由于位置更靠后，相同条件下仍然能覆盖导入的规则。动态插入的 <style> 标签通常被追加到 <head> 末尾，因此也会覆盖文档里较早出现的规则。
内联 style 属性则不能简单地用“后出现”来解释。它在层叠中拥有比任何普通选择器更高的特异性，所以即使内联样式写在文档最前面，也会覆盖后面 <style> 里的 class 选择器。这是另一种机制导致的覆盖，很多样式冲突的根源就在于把内联样式和顺序混为一谈。
选择器特异性与!important的真实权重
层叠的第二步是选择器特异性。一个最直观的算法是把选择器拆成三段：ID选择器数量、类选择器/属性选择器/伪类数量、元素选择器/伪元素数量。三个数字从左到右比较，前面的数字大就胜出。内联样式相当于放在最左边的更高一位，普通选择器没法直接覆盖它。
下面这张表列出了常见选择器的特异性对比：
| 选择器 | 特异性 (ID, 类, 元素) | 说明 |
|---|---|---|
* | (0,0,0) | 通配符不增加特异性 |
div | (0,0,1) | 元素选择器 |
.box | (0,1,0) | 类选择器 |
#main .box | (1,1,0) | ID + 类 |
<div style="color:red"> | (1,0,0,0) | 内联样式最高 |
需要注意的是，这个表里内联样式的特异性用四位表示，它不会被普通选择器压过。实际开发中如果必须覆盖内联样式，通常只能依靠 !important，或者修改模板和脚本不再输出内联样式。仅靠写更高的 class 选择器是无能为力的。
/* 这个规则无法覆盖内联样式 */
#main .box {
color: green;
}
/* 只有加上 important 才能压过内联样式 */
#main .box {
color: green !important;
}
!important 会反转同一来源内的层叠顺序。普通作者样式里，后出现的规则覆盖先出现的规则；但两个都带 !important 时，依然是后出现的 !important 规则覆盖先出现的 !important 规则。结合不同来源看，作者普通样式高于用户普通样式，但用户重要样式高于作者重要样式，浏览器重要声明则在更上面。因此把 !important 当成终极方案并不完全准确，只是在常规开发中用户样式很少启用，它才看起来像最高优先级。
常见覆盖冲突场景与排查方式
第一种冲突是引入顺序导致的覆盖。假设页面先引入了一个基础样式库，再引入项目自定义样式，项目样式写在后面，相同特异性下自然覆盖基础库中的规则。但如果需要用基础库修复自定义样式，就要注意调整 <link> 的顺序，或者提高自定义选择器的特异性。更稳妥的做法是自定义样式永远放在第三方样式之后引入，依靠顺序完成基础覆盖，再对有歧义的部分使用更具体的选择器。
第二种冲突是第三方组件使用内联样式或高特异性选择器，页面自己的 class 改不动。常见于某些富文本编辑器、图表库或者表格组件。此时如果直接用 !important 压住，后续维护会很痛苦。可以先用浏览器 DevTools 找到被覆盖的规则，确认它的来源文件和选择器，再决定是提高自己的特异性、移除内联样式，还是利用 CSS 变量覆盖组件内部使用的变量值。
排查时，在 Chrome DevTools 的 Elements 面板选中元素，右侧 Styles 栏里，被覆盖的声明会显示删除线，点击声明旁边的文件链接可以看到具体位置。如果发现一个声明来自内联样式，另一个来自外部文件，就说明不是简单调顺序能解决的，需要按优先级规则处理。
一个可维护的解决思路是：不跟组件库的选择器“硬碰硬”，而是利用 CSS 自定义属性控制主题。比如组件内部使用 var(--primary-color)，页面只需要在根上重新定义这个变量，就能改变大范围样式，不需要连续堆叠 !important。
:root {
--primary-color: #2f6fed;
}
/* 组件内部使用变量，外部覆盖变量即可 */
.button {
background: var(--primary-color);
}
日常维护中还可以借助 BEM 命名或工具类减少深层选择器，从源头上降低特异性冲突。如果已经出现必须提高特异性的情况，优先使用更具体的类名组合，而不是直接加 ID 或 !important。ID 会带来过高的特异性，后续想再覆盖又要写更多 ID，而且 !important 多了之后，层叠顺序会变得非常难追踪。
统一引入策略，降低覆盖成本
团队协作时，最好在项目初期就约定样式引入顺序和命名规范。比如先加载重置样式，再加载第三方基础库，最后加载项目自定义样式。避免在页面中随意嵌入 <style> 块或内联样式，因为零散的规则会让层叠来源变得复杂，出问题时很难定位。
如果必须使用 @import，尽量把它放在外部样式表顶部，而不是散落在 <style> 块里。多个 @import 会串行加载，影响首屏性能，也容易让规则插入位置变得混乱。对于运行时动态插入样式，建议统一通过一个样式管理器或者使用 CSS 模块方案，让样式仍然有明确的归属，而不是随意向 <head> 追加内容。
理解层叠和优先级之后，处理覆盖问题时可以先问自己三个问题：规则来自哪里、选择器特异性是多少、是否已经存在 !important。把这三个答案弄清楚，就能避免大部分盲目调试。最终目标不是记住所有优先级细节，而是让每次样式修改都有清晰的覆盖依据。