根本原因是minicssextractplugin按chunk依赖图和id重排顺序，而非保留js中import的物理顺序；vite则因默认合并css及@import导致sass降级而掩盖真实顺序问题。
Webpack生产环境CSS顺序变化的根本原因
不是浏览器变了，也不是代码写错了，而是 Webpack 在生产模式下默认启用 MiniCssExtractPlugin，它把 CSS 从 JS bundle 中抽出来单独成文件，并按 chunk 依赖图重排注入顺序——你写的 import 顺序，在构建后变成 chunk 的拓扑序，不再等于最终 <link> 标签顺序。
MiniCssExtractPlugin 如何打乱你的预期
这个插件不保留 JS 中 import 的物理顺序，而是根据模块依赖关系生成 CSS 文件，并按 Webpack 内部 chunk ID 排序输出 <link>。常见表现：
- 多个入口（如
app和admin）各自引入的 CSS，会分别打包为app.css、admin.css，但 HTML 中插入顺序取决于 entry 配置里哪个先定义 - 动态 import 的组件（如
import('./Modal.vue')）带的样式，会被打到异步 chunk，加载时机晚于主 chunk，<link>自然靠后 - 如果用了
splitChunks，公共 CSS（比如common.css）可能被提取到单独文件，但它的 chunk ID 可能比业务 CSS 还小，导致<link>插在中间而非最前
Vue CLI 或 Vite 默认配置加剧问题
Vue CLI 基于 Webpack，默认开启 MiniCssExtractPlugin；Vite 则默认将所有 CSS 合并为一个 style.css，看似“顺序固定”，实则掩盖了依赖冲突——一旦你用 @import 或第三方库（如未升级的 Bootstrap）混入 @import，Dart Sass 就降级为 legacy 模式，所有 @use 失效，样式拼接逻辑崩坏，输出顺序彻底失控。
关键点：Vite 的“单文件”只是表象，真正决定顺序的是 SCSS 编译阶段是否已因残留 @import 导致降级。
如何验证和锁定真实顺序源头
别看源码，直接查生成的 HTML 和 DevTools：
- 打开生产环境页面 → 查看页面源码 → 找所有
<link rel="stylesheet">，确认它们的物理排列顺序 - 在 DevTools 的 Elements 面板中选中目标元素 → Styles 面板里找被划掉的声明 → 点击来源文件名，跳转到对应
<link>，确认它是不是排在你期望覆盖它的样式之前 - 检查 Network 面板，确认每个 CSS 文件返回状态码是
200，排除路径错误或 CSP 阻断导致“根本没加载”的假错乱
最容易被忽略的是：构建工具注入的 CSS（比如通过 sassOptions.additionalData 自动注入的变量文件）也会参与 chunk 构建，但它不出现在源码 import 中，排查时容易漏掉。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
