import语句在CSS中触发串行加载，导致渲染阻塞；应改用并行的link标签，配合内容哈希、Brotli压缩、按需拆分及HTTP/2优化。
为什么 import 语句放在 <head> 里会阻塞渲染
浏览器解析 HTML 时，遇到 <link rel="stylesheet"> 或 <style> 就会暂停 DOM 构建，直到 CSSOM（CSS 对象模型）就绪。而 @import 在 CSS 文件内部使用时，更糟——它会触发**串行加载**，比如 a.css 里写了 @import "b.css"，那 b 必须等 a 下载并解析完才开始请求。
- 真实场景：用 Webpack 打包后仍手动在
index.html的<head>里写<link href="main.css" rel="stylesheet">，没问题；但若这个main.css里嵌了三层@import，首屏时间可能多出 300ms+ - 关键区别：
link是并行下载，@import是串行解析+下载，且不支持媒体查询懒加载（link支持media="print"等条件加载） - 兼容性陷阱：IE6–IE8 对
@import的位置敏感，写在<style>块末尾会被忽略
如何让 CSS 文件体积压缩真正生效
光用 css-minimizer-webpack-plugin 或 postcss-cli --minify 不够——压缩只是移除空格和注释，对体积影响有限；真正见效的是删除未用样式、拆分关键 CSS、启用 Brotli。
- 常见错误：Webpack 配置里开了
minimize: true，但没配splitChunks，导致所有组件样式全打进一个main.css，首屏加载冗余代码 - 必须做的三件事：
– 用critters提取并内联 above-the-fold CSS
– 在webpack.config.js中设置splitChunks.chunks: "all"+cacheGroups按路由/组件拆包
– Nginx 或 CDN 开启Brotli（比 Gzip 平均再省 15%） - 注意：
purgecss类工具对动态类名（如className={styles[theme]}）容易误删，需在content配置里显式声明模板路径
CDN 分发 CSS 时，缓存失效怎么不伤用户体验
改一个像素边框，就该让所有用户立刻看到新样式，但又不能强制所有人重下整个 CSS 文件——核心是靠文件内容哈希控制缓存粒度。
- 典型翻车：用时间戳或版本号当 query 参数，如
main.css?v=2.1.0，CDN 缓存失效，但浏览器可能因强缓存策略（Cache-Control: max-age=31536000）仍用旧文件 - 正确做法：
– Webpack 输出设filename: "[name].[contenthash:8].css"
– HTML 中通过html-webpack-plugin注入带 hash 的链接，确保文件变则 URL 变
– CDN 设置响应头Cache-Control: public, max-age=31536000，靠 URL 变更驱动更新 - 额外提醒：如果用了 CSS-in-JS（如 Emotion），
cache-busting要同步处理 JS bundle 的 hash，否则 JS 里生成的 class 名和 CSS 文件不匹配
HTTP/2 下还用不用合并 CSS 文件
不用。HTTP/2 多路复用消除了 HTTP/1.1 的“域名分片”“资源合并”必要性；强行合并反而损害缓存复用率和加载优先级控制。
立即学习“前端免费学习笔记（深入）”；
- 现实问题：老项目保留
vendor.css + app.css + theme.css合并逻辑，升级 HTTP/2 后未调整，结果每次主题色变更都要让用户重下全部三方库样式 - 推荐结构：
–critical.css（内联或 preload）
–base.[hash].css（重置、布局、字体等稳定基础样式）
–feature-a.[hash].css（按功能/路由异步加载） - 性能提示：Chrome DevTools 的
Network > Priority列能验证是否真按预期优先级加载；若多个 CSS 显示Low，检查有没有@import或document.write干扰解析
最易被忽略的是 CSS 加载时机与 JS 执行的耦合——比如在 DOMContentLoaded 回调里操作 DOM 样式，却没确认对应 CSS 是否已解析完成。这时候靠 document.fonts.load() 或 CSSStyleSheet.replace() 的 promise 更可靠，而不是赌加载顺序。
