Tailwind类名覆盖取决于CSS定义顺序而非HTML中class排列顺序，因所有工具类权重相同；!修饰符仅用于覆盖内联样式或第三方!important规则；@layer可使自定义样式与工具类平权；提升选择器权重比!important更可靠；应优先通过DevTools的Computed面板定位冲突根源。
为什么HTML里后写的类名不生效
Tailwind的类名覆盖不看你在class属性里怎么排列，而看它最终生成的CSS规则在文件里的定义顺序。所有bg-、text-、rounded-这类工具类默认权重都是0,0,1,0，完全相等。谁赢，只取决于PostCSS编译后它们在tailwind.css里谁排在后面。
比如bg-sky-500在默认配色中生成位置比bg-orange-500靠后，那无论你怎么写class="bg-orange-500 bg-sky-500"，bg-sky-500一定生效——不是因为HTML里它靠后，而是CSS里它定义得晚。
- 别指望靠调整HTML中class顺序来“强制覆盖”
- 构建缓存或Vite HMR异常时，可能让原本靠后的类意外跑到前面，导致样式翻车
- 真正可控的做法是：逻辑层只保留一个互斥类，比如用
v-if或computed动态推导出bg-sky-500或bg-orange-500，而不是堆在一起
什么时候该用!修饰符
!不是用来解决“两个Tailwind类谁赢”的问题，它是专治那些绕过class体系的硬编码样式：内联style属性、React组件里直接写padding: 0.5rem、第三方库用!important锁死的规则。
- 正确写法只有
text-red-500!、sm:p-4!——感叹号必须紧贴类名末尾 -
!text-red-500或sm:!p-4完全无效，PostCSS不会识别 - 滥用会导致后续覆盖变成
bg-blue-500! bg-red-500!，可读性崩坏 - 它只回答“谁赢”，不回答“为什么输”。先打开DevTools的Computed面板，确认冲突来源是内联style还是preflight重置，再决定要不要加
如何用@layer获得平等话语权
Tailwind默认把所有工具类塞进@layer utilities，而你手写的.card { @apply p-4; }如果不声明层级，就落在未归层或@layer base里——天然被压。
- 想让自定义样式和Tailwind工具类平起平坐，必须显式写
@layer components或@layer utilities -
@layer utilities要放在@tailwind utilities之前，否则你的定义会被覆盖 -
@apply不能跨层调用：在@layer base里用@apply调bg-blue-500（定义在utilities层）会静默失效 - 浏览器Styles面板里找
data-layer="components"标签，能快速验证你的层是否生效
提升选择器权重比!important更可靠
当text-blue-500被.el-button覆盖，不是Tailwind太弱，而是两者权重同为0,1,0，浏览器按加载顺序判输赢。此时加一层父容器前缀，比全局!important更精准。
- 手动加如
.my-page .btn（权重0,2,0），稳压.el-button - Vite项目推荐
vite-plugin-css-prefix自动加前缀，避免漏写或拼错 - ID选择器
#app .btn权重高但不稳定，尤其在Vue/React动态渲染下慎用 -
:where()和::is()不增加权重，别指望靠它们提权
最常被忽略的是：所有这些手段都只是“应对策略”，真正的解法藏在DevTools的Computed面板里——先看清哪条规则在生效、为什么生效，再选路径。否则容易在!、@layer、前缀之间反复横跳，却始终没碰到底层冲突点。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
