后引入的CSS会覆盖先引入的同权重样式，这是CSS层叠机制的设计而非bug；顺序决定覆盖关系，推荐硬性引入顺序：normalize.css → variables.css → base.css → components/.css → pages/.css或themes/dark.css。
为什么后引入的 CSS 会“赢”过前面的
浏览器按 标签在 HTML 中从上到下的顺序解析样式表，同权重规则下，后加载的直接覆盖先加载的——这不是 bug，是 CSS 层叠（cascade）机制本身的设计。比如 reset.css 里写了 button { margin: 0; }，但你把它放在 components/button.css 后面引入，那按钮就又冒出默认外边距了。
- 被覆盖的样式没消失，只是“失效”：DevTools 的 Styles 面板里会显示为带删除线（strikethrough）
- 哪怕两个文件都用
.btn，只要后者加载靠后，它的color、padding就会生效 -
@import会阻塞解析，且其导入内容在层叠中“算作”出现在@import那一行的位置，极易打乱预期顺序，生产环境应禁用
标准引入顺序不是建议，是防错底线
把 reset.css 放最后，等于主动放弃样式控制权；把 pages/home.css 放最前，等于让页面特例去约束所有组件。真正起作用的不是“谁更重要”，而是“谁更晚有机会改写”。
- 推荐硬性顺序：
normalize.css→variables.css（含:root自定义属性）→base.css（字体、工具类）→components/*.css（按钮、卡片等）→pages/*.css或themes/dark.css - 组件内部也有依赖：若
form.css用到了input.css定义的.input-text，就得确保input.css在它前面引入 - Webpack/Vite 项目中，顺序由 JS 入口的
import语句决定，不是 HTML 里的位置——别在 HTML 里手动写一堆然后指望构建工具尊重它
动态插入 CSS 时，顺序陷阱比静态更隐蔽
JS 创建 并 appendChild 到 ，默认插在末尾，天然“最强”——但这往往不是你想要的。比如换肤时注入 dark.css，如果它压过了 pages/home.css，首页微调就全丢了。
- 正确做法是插到目标节点之后：
document.head.insertBefore(newLink, baseLink.nextSibling) - 避免用
document.write()或在DOMContentLoaded后才插入关键样式，否则可能触发 FOUC（闪白） - 微前端场景下，各子应用独立注入 CSS，顺序完全不可控——此时单靠调整
顺序已无意义，必须用 CSS Modules、命名空间或 Shadow DOM 隔离作用域
查覆盖源比猜优先级更高效
别一上来就改选择器权重或加 !important。打开 Chrome DevTools → Elements → 选中元素 → Styles 面板，看哪条规则被划掉，悬停会提示 “This rule was overridden by …”，点击右侧文件名就能跳转到对应 标签或 CSS 行。
立即学习“前端免费学习笔记（深入）”；
- 如果被划掉的来自
base.css，而生效的是theme.css，说明引入顺序反了 - 如果被划掉的是内联样式（
）或 JS 注入的，那它本就该赢，问题不在顺序而在逻辑位置 - 多个
!important并存时，顺序仍是最终裁决者：后声明的赢，跟权重无关
真正难处理的不是顺序本身，而是当 CSS 来源混杂（框架、组件库、主题包、运行时注入、CSS-in-JS）时，连“谁在哪儿引入”都不可见。这时候光调 顺序只是隔靴搔痒。
