@import 在现代 css 中反而增大文件体积，因其阻塞解析、触发额外 http 请求、绕过构建优化，导致总体加载更慢、体积增加 10%–30%。
为什么 @import 在现代 CSS 中反而让文件更大
它不会减少主 CSS 文件体积，反而常导致总体加载更慢、体积更大。浏览器解析到 @import 时会阻塞后续规则解析，并发起新的 HTTP 请求（即使同域），无法与主文件并行下载；在构建工具中，它还容易绕过压缩、去重和 Tree-shaking。
- 开发时看着主文件变小了，但实际网络请求多了，总字节数常增加 10%–30%
- Webpack/Vite 等工具默认不内联
@import的内容，除非显式配置css-loader的importLoaders或启用postcss-import -
@import只能在样式表开头使用，位置错一位就会被整个忽略——连报错都不给，静默失效
用 postcss-import 替代原生 @import
这是目前最稳妥的“逻辑拆分 + 体积控制”方案：它在构建时就把子文件内容同步内联进来，保留模块化写法，又避免运行时开销。
- 安装：
npm install postcss-import --save-dev - 确保 PostCSS 配置里有：
require('postcss-import')，且放在postcss-preset-env或cssnano之前 - 路径支持相对/别名：
@import './base/variables.css';或@import '~@styles/mixins.css'; - 它会自动去重相同
@import，避免重复引入同一份 reset 或工具类
真正减小体积的关键动作不是拆，是删和压
分散文件只是表象，体积问题根子在冗余规则、未用选择器、低效写法。光靠 @import 拆分，不清理内容，等于把垃圾打包进多个小袋子。
- 用
purgecss或框架自带的content配置（如 Tailwind 的content数组）删除未使用的 CSS - 避免通配符重置：
* { margin: 0; padding: 0; }这种写法会被全量保留，哪怕只用了一个按钮 - 慎用
@import url(...)引入外部字体或 CDN 样式——它们不走构建流程，无法压缩，还多一次 DNS 查询 - 检查 sourcemap 是否误打进生产包：
devtool: 'source-map'在 production 下必须关掉
Vite / Webpack 中 CSS 合并后的体积验证方法
别信编辑器里看到的 .css 文件大小，要看最终产物中实际注入页面的那部分。
立即学习“前端免费学习笔记（深入）”；
- Vite：构建后打开
dist/assets/*.css，用gzip -l *.css看压缩后体积 - Webpack：加
webpack-bundle-analyzer插件，专门看css/mini-css-extract-plugin输出块 - 浏览器 Network 面板里查
style.css的Size和Content两列——前者是传输体积（含 gzip），后者是解压后大小，差太多说明压缩没生效 - 如果用了
@import但没配postcss-import，Network 里会看到多个 .css 请求，且主文件里只剩一行@import——这就是典型“假拆分”
实际项目里，@import 的路径拼写错误、插件加载顺序错位、以及 purging 规则漏配，三者叠加最容易导致“以为优化了，结果线上多加载了 200KB”。这些地方不跑一遍构建产物分析，光看代码结构根本发现不了。
