Webpack打包后CSS加载顺序不可信，因其按模块依赖图重排而非import顺序；最终生效顺序取决于HTML中<link>标签位置或main.css内规则实际排列，非JS中引入顺序。
Webpack打包后CSS加载顺序为什么不可信
你以为在index.js里先import 'bootstrap/dist/css/bootstrap.min.css'再import './custom.css'就稳了？Webpack 5 的 CSS 提取插件（比如mini-css-extract-plugin）会把所有 CSS 按模块依赖图重新排序，最终生成的main.css里，你的custom.css可能被插到 Bootstrap 规则中间甚至前面。
真正起作用的是最终 HTML 中<link>标签的顺序，或生产环境打包后main.css里规则的实际位置——不是你写的import顺序。
- 打开浏览器 Network 面板，过滤
css，确认bootstrap.min.css是否真在custom.css之前加载（状态码必须是200） - 如果是单文件输出（如
main.css），用浏览器查看源码，搜索.btn或.navbar-brand，看 Bootstrap 的规则是否出现在你自定义规则之前 - Vite 用户注意：
css.preprocessorOptions可能延迟注入，导致样式“闪一下”才生效
如何强制让自定义CSS在Bootstrap之后生效
别赌import顺序，直接控制输出位置。最稳妥的方式是：把自定义 CSS 单独作为<link>引入，并确保它在 Bootstrap 的<link>之后、</head>闭合前。
- 在
public/index.html里手动写：<link rel="stylesheet" href="%PUBLIC_URL%/css/custom.css">，且放在 Bootstrap 的<link>下方 - Webpack 用户可配置
html-webpack-plugin的inject: 'head'+chunksSortMode: 'dependency'，但不如手写<link>可靠 - 如果必须走 JS import，改用
import '!style-loader!css-loader!./custom.css'（开发环境），它会强制最后注入<style>标签
为什么!important在打包后更危险
Webpack 生产构建时，CSS 压缩工具（如css-minimizer-webpack-plugin）可能合并、重排带!important的规则，导致原本能压过 Bootstrap 的声明，被压缩后失效或错位。
立即学习“前端免费学习笔记（深入）”；
- DevTools 的 Computed 面板里，若看到某属性被划掉但来源显示
custom.css，大概率是压缩器搞乱了!important顺序 - Bootstrap 5.3+ 的部分工具类（如
.fw-bold）本身带!important，你加的!important未必能赢 - 真正该做的是提升选择器权重：
.navbar .navbar-brand.my-brand比.navbar-brand多一阶特异性，且不依赖!important
检查mini-css-extract-plugin是否干扰了顺序
这个插件默认按入口 chunk 顺序写入 CSS，但如果你有多个 entry（比如app.js和admin.js），它会为每个 chunk 生成独立 CSS 文件，而 HTML 插件可能按字母序插入<link>，导致 Bootstrap 被拆到admin.css里，反而晚于app.css中的自定义样式。
- 在
webpack.config.js中显式指定filename: 'static/css/[name].css'，避免 chunk 名混乱 - 禁用多入口 CSS 提取，改用单入口 +
splitChunks，确保 Bootstrap 和 custom 同属一个 chunk - 终极验证方式：构建后打开
dist/static/css/main.css，搜索.btn，确认 Bootstrap 规则确实在你自定义规则之前
!important和选择器结构的二次重排——它发生在你肉眼看不到的地方。 
