先看styles面板中被删除线划掉的样式，点击旁文件名跳转至位置；若其位于自定义css之前，则是顺序覆盖，需检查构建后html中真实顺序及network中css是否200。
怎么看是不是顺序问题，而不是写错了
别靠经验猜，直接用浏览器开发者工具定位：选中目标元素 → 右侧 Styles 面板里找带删除线（strikethrough）的样式声明 → 点击被划掉样式旁的文件名，跳转到对应 <link> 标签位置。如果它出现在你写的 CSS 文件之前，就是被覆盖了。
临时删掉其他 <link rel="stylesheet">，只留你的 CSS，强制刷新（Cmd + Shift + R 或 Ctrl + F5）看样式是否出现；同时检查 Network 面板，确认所有 CSS 文件状态码是 200，排除路径 404 干扰。
为什么本地看着对，构建后还是失效
Webpack/Vite 等构建工具会重写最终 HTML，你源码里写的 <link> 顺序可能被插件覆盖：
- Vite 中若启用了
css.preprocessorOptions或某些 CSS 注入插件，生成的<link>默认插在末尾 - Webpack 使用
MiniCssExtractPlugin时，CSS 合并顺序由 JS 入口里的import语句决定，不是 HTML 里的<link>位置 - 动态
import()加载的 CSS 不保证插入顺序，慎用于关键样式（如 reset、variables）
务必检查最终生成的 HTML（不是源 index.html），确认 <link> 实际顺序是否符合预期。
哪些操作会让顺序“看似正确实则失效”
这些细节容易被忽略，但一出问题就很难定位：
- 在 JS 里用
document.head.appendChild(linkEl)动态插入 —— 它永远在所有静态<link>之后 - 在
page.css里写@import "base.css"—— 这会让base.css实际加载时间晚于page.css，彻底颠倒层级 - 把
<link>写在里 —— 浏览器可能已开始渲染，导致 FOUC 或样式闪烁 - 用
rel="preload"加载样式表 —— 它不参与层叠顺序，只是预加载，真正应用仍靠后续同步<link>
真正难的不是调顺序，而是让顺序稳定
开发时手写 <link> 顺序没问题，但构建、部署环节常被工具链悄悄改写。比如 Vite 的 html 插件、Webpack 的 HtmlWebpackPlugin、甚至 SSR 框架的服务端注入逻辑，都可能打乱你精心排好的依赖链。最可靠的方式是：在 JS 入口统一控制 import 顺序，并用构建产物验证最终 HTML，而不是依赖肉眼检查源码。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
