Webpack的CSS提取不认import顺序，因其按模块依赖图拓扑排序并扁平化合并，而非JS中引入顺序；真正生效的是最终HTML中标签顺序或main.css内规则实际位置。
Webpack 的 CSS 提取不认 import 顺序
Webpack（尤其搭配 mini-css-extract-plugin）不会按你在 JS 里 import 的先后顺序拼接 CSS。它基于模块依赖图做拓扑排序，把所有 CSS 模块“扁平化”后合并进 main.css —— 你写 import 'bootstrap.css'; import './custom.css';，最终生成的文件里，.btn 规则可能出现在 .my-btn 后面，也可能穿插在中间。
这不是 bug，是插件设计使然：它优先保证 chunk 复用和提取效率，而非开发者直觉中的“引入即生效”。Vite 也类似，虽然默认按 import 顺序处理，但一旦启用 css.preprocessorOptions 或动态 import()，顺序就不可靠了。
组件内 import 全局 CSS 是最大隐患
很多项目在多个组件里各自 import '@/styles/variables.css'; 或 import 'element-plus/dist/index.css';，这会导致：
- 同一份 CSS 被多次打包进不同 chunk，最终插入顺序取决于 chunk 加载时机，完全随机
- 构建工具检测到重复模块，可能合并或丢弃某次引入，造成变量未定义或样式缺失
- 即使没报错，
variables.css里的:root { --primary: #007bff; }若晚于使用它的组件 CSS 加载，var(--primary)就会回退为初始值
HTML 中的 link 顺序 ≠ 构建后的实际顺序
你在 public/index.html 里手动写了 Bootstrap 在前、custom 在后，不代表上线后依然如此。原因包括：
-
html-webpack-plugin默认 inject: 'body' 或自动排序 chunks，可能把自定义 CSS 插到 Bootstrap 前面 - Vite 的
build.rollupOptions.output.manualChunks若未显式命名和排序，CSS 可能被分进不同 chunk 并异步加载 - 某些 CDN 或代理服务会重写 HTML，删掉或移动
标签
真正有效的判断方式：打开生产环境页面 → 查看源码（不是 Elements 面板）→ 找最终生成的 标签顺序，或直接打开打包后的 main.css 搜索关键选择器位置。
scoped 样式救不了全局覆盖需求
用 确实能防止污染，但它只对组件内部生效。当你想覆盖 Bootstrap 的 .navbar-brand 或 Element Plus 的 .el-button 时，scoped 生成的属性选择器（如 .el-button[data-v-abc123]）权重低于原生类名，根本压不过。
这时候强行加 !important 更危险：CSS 压缩器（如 css-minimizer-webpack-plugin）可能合并规则、重排带 !important 的声明，导致本地有效、线上失效。
真正该做的是放弃“覆盖”，改用更高特异性选择器，例如：.my-app .navbar .navbar-brand > .navbar-brand，且全程避免 !important。
最麻烦的点不是搞不清谁先谁后，而是顺序在开发、构建、部署三个环节各自独立变化 —— 本地 npm run serve 正常，npm run build 后出问题，上了 CDN 又变个样。盯住最终 HTML 和打包产物，别信任何中间态的 import 或 link。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
