直接调换<link>顺序是最可靠解法，必须按“reset→variables→组件→页面/主题”语义层级排列；被划掉的样式即被覆盖，点击文件名可定位<link>位置，最终HTML中实际顺序才作数。
直接调换 <link> 顺序是最可靠解法，不是“可能有效”，而是“必须这么做”。其他所有技巧——加前缀、提权重、用 !important——都是在顺序失控后的补救手段。
怎么确认真是被覆盖，而不是没加载或写错了
别凭感觉猜，打开 Chrome DevTools → Elements 面板 → 选中目标元素 → 看右侧 Styles 面板：
- 被划掉（strikethrough）的样式，说明它输了；没被划掉但没生效，大概率是属性不继承、
display被重置，或transform导致视觉偏移 - 点击划掉样式旁的文件名，跳转到对应
<link>标签位置——如果它出现在你自定义 CSS 之前，就是顺序问题 - 检查 Network 面板，确认所有 CSS 文件状态码是
200，排除路径错误或 404
调整 <link> 顺序的硬性规则
不是“谁后引入谁赢”，而是按语义层级排列，确保每层都为上一层留出覆盖空间：
-
reset.css或normalize.css必须排第一，否则后续所有margin/padding都可能被浏览器默认样式干扰 -
variables.css（含css custom properties）必须在使用它的文件之前加载，否则var(--primary)会回退为初始值 - 组件级样式（如
button.css、card.css）放中间，复用性强、通用性高 - 页面/主题专属样式（如
home-page.css、dark-theme.css）必须放在最后——它们才是最终决策者
构建工具里顺序为什么还是乱
Vite/Webpack 不会照抄你 HTML 里的 <link> 顺序，它们按 JS 入口里的 import 语句合并 CSS：
立即学习“前端免费学习笔记（深入）”；
- Vite 中若启用了
css.preprocessorOptions或某些 CSS 注入插件，生成的<link>默认插在<head>末尾 - Webpack 用
MiniCssExtractPlugin时，CSS 合并顺序由 JS 入口里的import语句决定 - 动态
import()加载的 CSS 不保证插入顺序，慎用于关键样式 - 务必检查最终生成的 HTML（不是源
index.html），确认<link>实际顺序是否符合预期
哪些操作会让顺序“看似正确实则失效”
这些细节一出问题就极难定位，但非常常见：
- 在 JS 里用
document.head.appendChild(linkEl)动态插入 —— 它永远在所有静态<link>之后 - 在
page.css里写@import "base.css"—— 这会让base.css实际加载时间晚于page.css，彻底颠倒层级 - 把
<link>写在<body>里 —— 浏览器可能已开始渲染，导致 FOUC 或样式闪烁 - 用
rel="preload"加载样式表 —— 它不参与层叠顺序，只是预加载，真正应用仍靠后续同步<link>
真正难的不是调顺序，而是让顺序在开发、构建、部署各环节都稳定一致。尤其当项目接入微前端、SSR 或多主题切换时，一个动态插入或插件配置偏差，就足以让整套样式层级崩塌。
