根本原因是rollup按依赖图重排样式注入顺序；最可靠解法是改用html中显式声明。vite开发时import顺序有效，但生产构建中css被合并进chunk，最终顺序由chunk id和manualchunks配置决定，与源码import脱钩。
直接结论：Vite生产构建中CSS加载顺序错乱，根本原因不是你写错了import，而是Rollup按依赖图重排了样式注入顺序；最可靠解法是放弃JS里import './xxx.css'控制顺序，改用HTML中<link>显式声明。
为什么main.js里import顺序对不上最终CSS生效顺序
Vite开发时（vite dev）走ESM原生加载，CSS按import顺序逐个请求，看起来“对”；但生产构建（vite build）走Rollup打包，所有CSS被合并进chunk，最终插入页面的<link>顺序由chunk id和manualChunks配置决定，和源码import语句顺序完全脱钩。
- 检查最终HTML：打开
dist/index.html，看<link rel="stylesheet">标签物理顺序是否符合预期 - 若顺序不对，说明构建插件已重排——此时改
main.js里的import顺序毫无作用 - 尤其注意动态导入（
defineAsyncComponent、路由component: () => import(...)）会把对应CSS打到异步chunk，可能晚于主chunk加载
如何强制reset.css最先加载且不被覆盖
基础样式（如reset.css、variables.css）必须在所有组件样式之前生效，否则变量未定义、重置失效。靠JS导入不可控，应双管齐下：
- 在
public/index.html的顶部手动加<link rel="stylesheet" href="/reset.css">，路径需匹配base配置 - 同时在
vite.config.ts中禁用该文件被JS再次import：通过optimizeDeps.exclude或css.preprocessorOptions.scss.additionalData注入变量，避免重复打包 - 若用Sass/Less，把
@import 'variables.scss'写进additionalData，而非让每个组件CSS自己@import——后者会触发串行阻塞加载
使用manualChunks调整CSS chunk顺序的实操陷阱
build.rollupOptions.output.manualChunks能干预chunk生成，但极易踩坑：
- 函数式写法比对象式更可控：
manualChunks: (id) => { if (id.includes('reset.css')) return 'vendor-base'; }，避免正则误匹配 - 返回的chunk名（如
'vendor-base'）需确保在HTML中被最先加载：Vite默认按chunk name字典序插入<link>，所以命名用'00-vendor-base'比'base'更稳妥 - 切勿把CSS和JS混在一个chunk里——
mini-css-extract-plugin类逻辑在Vite中由rollup-plugin-css-only等插件接管，chunk拆分不当会导致样式丢失 - 验证方式：构建后查
dist/assets/目录，确认00-vendor-base.*.css存在且被index.html第一个<link>引用
为什么@import和preload都不能解决顺序问题
@import在CSS文件内使用，本质是运行时串行阻塞加载：哪怕base.css里最后一行写@import 'theme.css'，浏览器也必须等base.css完整下载解析完才发起theme.css请求，实际生效时间远晚于同级<link>；rel="preload"只预取资源，不应用样式，漏掉后续同步<link rel="stylesheet">就等于没加载。
- 禁止在任何业务CSS中写
@import，包括Sass/Less的@import——它只应在构建时展开，输出必须是单文件 -
rel="preload"仅适合关键路径CSS（如首屏必需），且必须配对<link rel="stylesheet"> - 真正需要顺序保障的样式（reset、variables、framework），唯一可信路径是HTML中的
<link>物理顺序
最易被忽略的一点：微前端场景下，子应用自己的<link>插入时机受主应用JS控制，此时连HTML顺序都不可信——必须用disabled属性+JS切换，而不是依赖加载先后。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
