优先用 而非 @import，因后者阻塞解析且引发串行请求；http/2 下按渲染关键路径拆分 css，内联首屏样式并动态加载非关键样式。
用 link 还是 @import？浏览器加载行为完全不同
@import 会阻塞后续 CSS 解析，且在 CSS 文件里写 @import 时，它还会触发额外的串行 HTTP 请求。现代项目里基本没理由用它。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 所有外部样式表统一用
<link rel="stylesheet">写在中 - 避免在 CSS 文件里嵌套
@import url(...)，尤其别跨域名或带查询参数 - 如果必须条件加载（比如主题切换），优先用 JS 动态创建
<link>并控制media属性
合并 CSS 文件真能提速？得看 HTTP/2 和缓存策略
HTTP/1.1 下合并文件确实减少请求数，但 HTTP/2 支持多路复用，单个大文件反而可能拖慢首屏——因为浏览器要等整个文件下载完才能解析关键样式。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- HTTP/2 环境下，按「渲染关键路径」拆分：把
above-the-fold样式内联或单独打包为critical.css - 非关键 CSS（如打印样式、后台管理页专用）用
rel="preload"+onload注入，或设media="print"后动态切回all - 合并前先查构建产物中是否有重复引入（比如多个
node_modules组件自带同名重置样式）
Webpack/Vite 怎么做 CSS 提取和分块？别只配 mini-css-extract-plugin
默认配置容易把所有 CSS 打进一个 main.css，导致异步路由组件的样式也被提前加载，白屏时间变长。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- Vite 项目开
build.cssCodeSplit: true（默认已开启），确保每个异步 chunk 对应独立 CSS - Webpack 配
mini-css-extract-plugin时，配合splitChunks.chunks: "all"和cacheGroups按业务模块分组 - 慎用
optimization.splitChunks.name: true—— 自动生成的名字不可控，可能破坏缓存一致性 - 检查最终产物里是否出现
chunk-vendors.css和chunk-xxx.css共存但内容重叠的情况
内联关键 CSS 的边界在哪？别把整页样式都塞进 <style></style>
内联太多 CSS 会让 HTML 体积暴涨，影响 TTFB 和 gzip 效率；内联太少又导致 FOUC 或布局跳动。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 只提取首屏可见区域（
viewport内）用到的选择器，工具推荐critters（Vite/webpack 插件）或penthouse - 避开含
:hover、@media (min-width: ...)等非初始状态的规则，它们不该进内联块 - 服务端渲染（SSR）项目注意：内联 CSS 必须和后端生成的 HTML 结构严格匹配，否则 hydration 时样式错乱
最麻烦的其实是第三方 UI 库的样式处理——它们通常没提供按需导出机制，得靠 PostCSS 插件或构建时 AST 分析来剔除未使用的规则。这点容易被忽略，但直接影响最终包体积。
