引入两个以上的第三方CSS库之后，页面突然就乱了：自己写的按钮样式被库里的默认样式盖住，弹窗位置飘了，字体也变了。这种情况在混用Bootstrap和Element UI、或者在老项目里追加Tailwind时特别常见。要解决它，先得弄明白浏览器层叠样式表的基本规则，再从引入顺序、选择器优先级和加载方式几个层面下手。
为什么后引入的样式会覆盖前面的
CSS的全称是层叠样式表，层叠指的就是当多条规则作用于同一个元素时，浏览器需要决定谁说了算。这个决策过程分三步：先看来源和重要性，再看选择器优先级（specificity），最后看书写顺序。当两个规则的选择器优先级完全相同、且都没有加!important时，后出现的那条规则获胜。这就是调整引入顺序能够解决问题的理论依据。
举个例子，Bootstrap里定义了.btn的圆角和背景色，你自己的业务代码也定义了.btn。如果Bootstrap的样式表在你自己的样式之后加载，那么恭喜你，辛辛苦苦写的按钮样式全部失效。反过来，把业务样式放到最后引入，覆盖问题立刻消失。
需要注意的是，顺序规则只在优先级相同时才生效。如果对方用的是.card .btn这种两层选择器，而你只用了一个.btn，那不管你怎么调整引入顺序，输的永远是你。所以遇到冲突时，第一步应该是打开开发者工具，看被覆盖的属性到底输在了哪一条规则上，再对症下药。
引入顺序的调整方法与加载差异
最直接的方式是控制<link>标签的顺序。把基础样式库（如normalize.css、Bootstrap）放在前面，把组件库样式放中间，把你自己的业务样式放在最后：
<!-- 1. 基础重置样式最先引入 --> <link rel="stylesheet" href="normalize.css"> <!-- 2. 第三方组件库样式 --> <link rel="stylesheet" href="bootstrap.min.css"> <!-- 3. 业务自定义样式必须放在最后 --> <link rel="stylesheet" href="app.css">
如果项目是用Webpack或Vite构建的，引入顺序由import语句的先后决定。以Vite项目为例，main.js里的写法顺序就是最终注入页面的顺序：
import 'normalize.css';
import 'element-plus/dist/index.css';
import './assets/app.css'; // 自定义样式放在最后一个导入
import { createApp } from 'vue';
import App from './App.vue';这里有个容易踩的坑：@import和<link>的加载机制不同。@import写的CSS会在页面其他样式加载完之后才开始请求，实际生效顺序往往比看起来晚。另外，CSS规范要求@import必须出现在样式文件的最顶部，写在后面会被浏览器直接忽略，这也是很多人调了半天顺序却毫无效果的常见原因。建议在构建工具普及的今天，统一用import语句管理样式依赖，避免混用两种方式带来的不可控顺序。
顺序解决不了时：提升优先级的几种手段
当第三方库的选择器优先级比你的高，光靠顺序就没用了，此时需要主动提升自己样式的优先级。第一种方式是细化选择器，比如把.btn写成.page .btn或者.wrap .list .btn，每多一层选择器，优先级就高一级。这种方式语义清晰，是最推荐的做法。
第二种方式是使用:where()和:is()配合。如果你维护的是自己团队的基础库，可以用:where()把选择器优先级降为零，这样下游业务方哪怕用最简单的单类选择器也能覆盖你：
/* 基础库中使用 :where 降低优先级 */
:where(.card) {
padding: 16px;
border-radius: 8px;
}
/* 业务代码用单类选择器即可轻松覆盖 */
.card {
padding: 24px; /* 生效，因为:where内部优先级为0 */
}第三种是!important，能不用就不用。它确实能一招制敌，但会在项目里引发军备竞赛，一旦双方都加上!important，最终又回到比拼顺序的老路，而且维护成本成倍增加。只有在覆盖第三方内联样式或确实无法修改HTML结构时，才考虑作为最后手段。
最后还有一种工程化思路：利用PostCSS插件或者构建配置，在打包阶段自动给第三方库的样式统一加上命名空间前缀，比如把Bootstrap的全部规则包裹在.lib-bootstrap作用域下，从根源上隔离两个库的选择器。适合大型项目长期共存多个UI库的场景。
排查冲突的实用技巧
Chrome开发者工具的Elements面板中，Styles区域会按优先级从高到低列出所有命中当前元素的规则，被覆盖的属性会显示删除线。顺着这个列表往上找，就能看到是谁把你的样式压下去了。如果发现某条规则来自根本没用到的库，说明可能存在冗余引入，直接移除比任何覆盖手段都干净。
另一个技巧是善用Computed面板，它可以确认元素最终生效的属性值，再配合.cls-btn这类明显区别于第三方命名风格的自定义类名前缀，能大幅降低撞名概率。团队协作时约定好命名空间，比如业务类统一以biz-开头，可以从制度上避免大部分样式冲突。
总结一下：优先调整引入顺序解决同优先级的覆盖问题；优先级不够就细化选择器或用:where()降低对方优先级；!important留作兜底；长期方案是命名空间隔离。掌握这几层手段，第三方CSS库打架的问题基本都能稳妥处理。