真正靠谱的做法是用构建工具接管CSS合并：开发阶段保留多个文件便于协作，上线前用PostCSS（postcss-import+cssnano）内联@import、压缩优化，禁用可能误删样式的插件如discardDuplicates和mergeLonghand，并通过postcss-reporter监控日志。
多个 .css 文件怎么合并成一个？
直接手动拼接会丢掉源码结构、注释错乱，还容易漏掉 @import 依赖。真正靠谱的做法是用构建工具接管——不是“能不能”，而是“该不该让 CSS 文件保持分离”。开发阶段保留多个文件利于定位样式、协作修改；上线前再合并压缩。
常见错误现象：404 报错一堆，但检查发现只是 @import url("reset.css") 路径没跟着主文件调整；或者合并后 :hover 效果失效，其实是层叠顺序被意外打乱。
- 用
postcss-import处理@import，它会在构建时内联引入，路径按当前文件为基准解析 - 避免在 CSS 里写相对路径如
../fonts/icon.woff，改用构建工具的资源别名（比如~assets/fonts/icon.woff） - 合并后务必检查
!important的实际生效顺序——多个文件合并后，后写的规则不一定“后加载”，得看最终输出的顺序
用 PostCSS + cssnano 打包压缩可行吗？
完全可行，而且比 Webpack 的 css-loader 更轻量、更可控。关键不是“能不能压”，而是“压完会不会改行为”：比如 cssnano 默认启用 discardDuplicates，遇到重复的 .btn { color: red; } 会删掉后一个——但如果两个规则分别来自不同组件库，删掉可能就丢样式了。
- 压缩前先跑一遍
postcss-discard-comments清理无用注释，别依赖cssnano自带的清理逻辑 - 禁用
mergeLonghand，它会把margin-top: 10px; margin-bottom: 10px;合成margin: 10px 0;，但某些旧版 Android WebView 对简写支持不一致 - 加
postcss-reporter输出处理日志，尤其关注 “Removed X duplicate rules” 这类提示
@import 在外部 CSS 文件里还能用吗？
能用，但构建时必须显式启用 postcss-import 插件，否则它就当普通字符串忽略。很多人误以为浏览器支持 @import 就等于构建工具也认，结果打包完还是多个 HTTP 请求。
使用 ImageMagick 的 convert 和 mogrify 命令进行批量图像处理，支持调整大小、裁剪、水印和格式转换。与 libvips 集成以实现高性能缩略图生成。
立即学习“前端免费学习笔记（深入）”；
-
@import只支持.css和.pcss后缀，不支持.scss或.less——那是预处理器的事，别混 - 路径必须是字符串字面量，不能拼接变量：
@import "base/" + $theme + ".css"是非法的，PostCSS 不做变量计算 - 如果用了
postcss-url，它会自动重写@import里的相对路径，但只处理同级或子目录，跨出项目根目录的引用会失败
要不要用 Sass/Less 替代纯 CSS 合并？
没必要只为合并而上预处理器。Sass 的 @use 和 @forward 确实更安全，但代价是增加编译步骤、锁死语法、团队要统一规范。如果你只是想把几个现成的第三方 CSS（比如 normalize.css、highlight.js 主题）合起来，PostCSS 足够干净利落。
- 预处理器对
@import的处理逻辑和 PostCSS 完全不同：Sass 会把所有@import内容展开到同一作用域，可能导致变量冲突；PostCSS 则严格按文件边界隔离 - 如果已有
tailwind.css或bootstrap.css这类大体积文件，用 Sass 导入反而会让编译变慢，因为 Sass 会尝试解析全部内容（哪怕你只用其中 10%） - 真正值得切预处理器的信号是：你开始写
@mixin、$color-primary、循环生成栅格——而不是“我想少发几个请求”
合并本身不难，难的是搞清哪些规则会被重排、哪些路径会失效、哪些压缩选项其实在悄悄删你的代码。越想省事越要盯紧构建日志里那几行 warning。
