@import 是 CSS 体积优化的反面典型，会阻塞渲染、串行加载；应改用构建工具内联合并，关键样式内联 HTML，非关键样式用 media 属性或动态加载，并借助 purgecss 等工具做 Tree-shaking。
用 @import 引入 CSS 是体积优化的反面典型
很多人误以为用 @import 可以“按需加载”或“拆分逻辑”，实际它会阻塞渲染，且无法并行下载。浏览器遇到 @import 时，必须先下载并解析完被引入的文件，才能继续处理后续样式，导致关键 CSS 加载延迟。更糟的是，多个嵌套 @import（比如 A.css → @import B.css → @import C.css）会形成串行请求链。
- 避免在主
style.css中使用@import引入其他 CSS 文件 - 若需模块化管理，改用构建工具（如 PostCSS、Webpack）做
@import内联 —— 即编译时展开合并，运行时只剩一个请求 - 开发期可保留
@import提高可维护性，但构建后必须确保它不落地到 HTML 的<link>或最终 CSS 文件中
<link rel="stylesheet"> 的加载行为直接影响首屏性能
默认情况下，<link rel="stylesheet"> 是渲染阻塞的，但可通过属性微调加载优先级和时机。重点不是“少引几个”，而是“什么时候引、怎么引”。
- 核心样式（如重置、布局、字体）必须内联进 HTML 的
<style></style>标签，避免额外请求 - 非关键 CSS（如打印样式、主题切换样式、页面底部组件样式）加
media属性，例如：<link rel="stylesheet" href="print.css" media="print">
，浏览器不会立即下载 - 动态加载的 CSS（如某个弹窗打开后才需要的样式）不要写死在 HTML 中，改用 JS 动态创建
<link>并插入head，配合onload回调控制使用时机
构建阶段的 CSS 拆分与 Tree-shaking 很难靠手写实现
CSS 本身没有导出/导入语义，所谓“Tree-shaking”必须依赖工具链识别未使用的选择器。纯手工删代码不仅低效，还容易误删（比如 JS 动态添加的 class 对应的样式）。
- 启用
cssnano（PostCSS 插件）做压缩：去除空格、合并重复声明、转为简写等 - 用
purgecss或unocss扫描 HTML/JS 模板，剔除未匹配的选择器；注意配置白名单（如js-、is-active等运行时 class 前缀） - 避免全局污染式写法，例如
body * { ... }或无限制的属性选择器，这类规则无法被工具安全删除 - 慎用 CSS-in-JS 库（如 styled-components）的“动态样式”功能，它可能生成大量散列类名，反而增大体积
字体、图标、背景图等资源常是隐藏的体积大户
很多人只盯着 .css 文件大小，却忽略 CSS 中引用的外部资源：WOFF2 字体动辄 100KB+，SVG 图标 inline 后可能比原文件还大，base64 编码的图片直接膨胀 33%。
立即学习“前端免费学习笔记（深入）”；
- 字体只加载需要的字重和字符集，用
font-display: swap避免 FOIT，但别把整套 Noto Sans 全引过来 - 图标优先用 SVG Sprite 或
<svg></svg>内联，而非字体图标（Font Awesome 的 Web Font 方案已明显过时） - 避免在 CSS 中用
url(data:...)内联大图；小图标（ - 检查
background-image是否指向了未压缩的 PNG / JPG，用 WebP 或 AVIF 替代，并配@supports回退
真正卡住首屏的往往不是 CSS 文件大小本身，而是它的加载方式和关联资源。很多项目把 CSS 压到 50KB 以下，却因一个 @import 或一张未优化的背景图，让关键渲染时间多等 800ms。优化得从网络请求链路出发，而不是盯着 gzip 后的数字。
