CSS加载顺序决定样式覆盖结果，需将基础样式置于head最前，避免@import和动态插入导致的竞态；构建时须显式控制chunk优先级并验证HTML中link顺序。

样式表引入顺序直接影响最终渲染效果

CSS 的层叠规则（Cascading）决定了后加载的样式会覆盖先加载的同名规则。如果 common.css 在 page.css 之后加载，但设计本意是让 common.css 作为基础样式兜底，那 page.css 里的重写就可能失效或被意外覆盖——问题往往出现在构建工具自动排序、异步加载、@import 嵌套或微前端样式隔离场景中。

link 标签位置和 rel 属性决定加载时机与阻塞行为

默认同步阻塞渲染，浏览器按 DOM 中出现顺序依次下载、解析、应用。一旦插入位置错误（比如动态 append 到 末尾），就可能晚于内联 或已解析的 CSSOM，导致 FOUC 或样式闪烁。

• 始终将基础样式（如重置、工具类、主题变量）放在 最前面
• 避免在 中使用 ，除非明确需要延迟加载且不参与首屏渲染
• 慎用 rel="preload" + as="style"：它只预加载，不自动应用，需配合 onload 动态插入 ，此时插入顺序必须手动控制

@import 在 CSS 文件内会引发串行加载与优先级陷阱

@import 不仅强制同步加载（即使写在文件末尾），还会让被导入样式表的规则权重等同于当前文件——但加载时机滞后，容易造成「样式已声明却未生效」的竞态。更隐蔽的是：若 A.css @import B.css，而 HTML 又直接 ，B 就会被加载两次，且两次解析的 CSSOM 可能因顺序不同产生冲突。

• 构建阶段一律用 PostCSS 或 Sass 的 @use/@forward 替代运行时 @import
• 禁止在已由构建工具处理的 CSS 文件中写 @import url(...)
• 若必须动态加载，用 JS 创建 并插入到目标 之前，而非追加到 末尾

构建产物中 CSS 文件名哈希与加载顺序脱钩

Webpack/Vite 等工具生成带 contenthash 的文件名（如 index.abc123.css），但 HTML 模板里仍按固定名字引用。一旦多个 chunk 输出 CSS 且未显式声明依赖关系，HTML 插件（如 HtmlWebpackPlugin）可能按字母序或 chunk id 排序插入，导致 button.789xyz.css 在 reset.fgh456.css 之前加载——基础样式反而后到。

立即学习“前端免费学习笔记（深入）”；

• 在 Webpack 中为 CSS chunk 显式配置 chunkFilename: '[name].[contenthash:8].css' 并确保 optimization.splitChunks 的 cacheGroups 有明确优先级（数值越小越靠前）
• Vite 项目检查 build.rollupOptions.output.manualChunks 是否按语义分组（如 vendor、base、pages），并确认 HTML 插件按此顺序注入
• 上线前用 curl -s your-site.com | grep '.css' 验证实际 HTML 中 的 DOM 顺序是否符合预期

最易被忽略的点：CSS 加载顺序问题通常不会报错，只有视觉异常或开发者工具里看到规则被划掉才暴露。一旦涉及 SSR、微前端、CDN 缓存或第三方脚本注入样式，顺序更难追踪——建议把关键样式表的 href 和插入位置写进构建日志，上线后自动比对 DOM 结构。