后解析到的声明胜出，因CSS规范规定权重相同时“后者指定者获胜”，实际顺序取决于构建后注入DOM的时机而非书写顺序。
权重相同时谁生效，取决于浏览器的层叠算法而非“随机”
这不是 bug，是 CSS 规范明确定义的行为：当两个规则的 specificity、来源（origin）和重要性（!important）完全一致时，后解析到的那条声明胜出。W3C 标准写得清楚：“the latter specified wins”。所谓“后面”，指的是 CSS 解析器最终看到的规则顺序，不是你写的顺序，也不是文件物理顺序，而是构建后注入 DOM 的顺序。
为什么本地看着好使，上线就失效
常见原因不是“顺序变了”，而是构建过程悄悄改了规则的落点：
-
Vite或Webpack的 CSS 提取插件（如mini-css-extract-plugin）可能把组件 scoped 样式、全局样式、动态 import 的样式打乱重排 -
Vue的<style scoped>生成的属性选择器（如[data-v-abc123]）权重等同于类，但因 runtime 插入时机靠后，常“意外赢过”静态引入的.btn - 第三方 SDK（比如埋点、UI 组件库）通过 JS 动态插入
<style>，默认追加到<head>末尾，天然比 HTML 中的<link>靠后
怎么验证是不是真的权重相同
别猜，用 Chrome DevTools 实锤：
- 选中目标元素 → 打开
Styles面板 → 看右侧被划掉的规则，悬停会显示This rule was overridden by … - 重点核对三项：
Specificity（如0,0,1,0）、Source（来自哪个文件/行号）、是否含!important - 如果两个规则都显示
0,0,1,0，且都没!important，那胜负就只看Source列里谁在更下方——那个才是“后者”
真正可靠的解法不是调顺序，而是提权
依赖顺序等于把控制权交给构建工具和 runtime，风险太高。应该主动打破权重相等：
立即学习“前端免费学习笔记（深入）”；
- 用容器限定：
.my-app .btn（0,0,2,0）比裸.btn（0,0,1,0）高 - 加属性选择器：
.btn[data-role="primary"]权重也是0,0,2,0，且语义清晰 - 避免
@import：它不提升优先级，还阻塞解析；改用<link rel="stylesheet">显式控制加载链 - 慎用
!important：它只豁免单条声明，不改变选择器权重；一旦用了，后续所有覆盖都得跟它对齐，调试成本指数上升
specificity 计算不是加法，而是四元组逐位比较。哪怕你多写一个无意义的标签选择器（如 button.btn），权重就从 0,0,1,0 变成 0,0,1,1，直接压过 .btn——这种微小改动，比反复调整引入顺序靠谱得多。 
