CSS加载顺序决定样式覆盖结果，需将基础样式置于head最前，避免@import和动态插入导致的竞态；构建时须显式控制chunk优先级并验证HTML中link顺序。
样式表引入顺序直接影响最终渲染效果
CSS 的层叠规则（Cascading）决定了后加载的样式会覆盖先加载的同名规则。如果 common.css 在 page.css 之后加载，但设计本意是让 common.css 作为基础样式兜底，那 page.css 里的重写就可能失效或被意外覆盖——问题往往出现在构建工具自动排序、异步加载、@import 嵌套或微前端样式隔离场景中。
link 标签位置和 rel 属性决定加载时机与阻塞行为
<link rel="stylesheet"> 默认同步阻塞渲染，浏览器按 DOM 中出现顺序依次下载、解析、应用。一旦插入位置错误（比如动态 append 到 <head> 末尾），就可能晚于内联 <style> 或已解析的 CSSOM，导致 FOUC 或样式闪烁。
- 始终将基础样式（如重置、工具类、主题变量）放在
<head>最前面 - 避免在
<body>中使用<link rel="stylesheet">，除非明确需要延迟加载且不参与首屏渲染 - 慎用
rel="preload"+as="style"：它只预加载，不自动应用，需配合onload动态插入<link>，此时插入顺序必须手动控制
@import 在 CSS 文件内会引发串行加载与优先级陷阱
@import 不仅强制同步加载（即使写在文件末尾），还会让被导入样式表的规则权重等同于当前文件——但加载时机滞后，容易造成「样式已声明却未生效」的竞态。更隐蔽的是：若 A.css @import B.css，而 HTML 又直接 <link href="B.css">，B 就会被加载两次，且两次解析的 CSSOM 可能因顺序不同产生冲突。
- 构建阶段一律用 PostCSS 或 Sass 的
@use/@forward替代运行时@import - 禁止在已由构建工具处理的 CSS 文件中写
@import url(...) - 若必须动态加载，用 JS 创建
<link>并插入到目标<link>之前，而非追加到<head>末尾
构建产物中 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 中<link>的 DOM 顺序是否符合预期
<!-- ✅ 正确顺序示例 --> <head> <link rel="stylesheet" href="/css/reset.1a2b3c.css"> <link rel="stylesheet" href="/css/vendor.4d5e6f.css"> <link rel="stylesheet" href="/css/app.7g8h9i.css"> </head>
最易被忽略的点：CSS 加载顺序问题通常不会报错，只有视觉异常或开发者工具里看到规则被划掉才暴露。一旦涉及 SSR、微前端、CDN 缓存或第三方脚本注入样式，顺序更难追踪——建议把关键样式表的 href 和插入位置写进构建日志，上线后自动比对 DOM 结构。
