CSS 压缩的作用是把代码里的空格、换行、注释去掉，变量名能短就短，让文件体积变小、网页加载更快。压缩本身没有问题，问题在于很多人把压缩后的文件直接提交到代码仓库，甚至覆盖了原始文件，导致同事拉取代码后看到的是难以阅读的内容。正确的做法是：写给人看的源文件放进仓库，压缩交给构建阶段自动完成，压缩产物输出到构建目录或直接打包进上线产物，不提交到版本控制。
CSS 压缩到底做了什么
压缩工具处理 CSS 时，通常会做这几件事：
- 删除空格、换行和缩进
- 删除注释
- 合并重复的规则和声明
- 缩短颜色值、单位等可简写的写法
- 在安全的前提下缩短选择器或变量名
结果是文件体积变小，但可读性基本归零。压缩后的代码是给浏览器看的，不是给人看的。它的目标只有一个：让页面加载更快。
为什么压缩文件不该进仓库
把压缩产物提交到仓库，会带来几个直接后果：
第一，同事拉取代码后，看到的是没有缩进、没有注释、挤成一团的字符，无法正常阅读和维护。
第二，一旦压缩文件覆盖了原始文件，人可读的源文件就丢失了。后续想改样式，只能面对压缩后的代码，修改成本极高。
第三，压缩产物是构建结果，不是源材料。把它放进版本控制，等于把每次构建的中间产物都当成源码管理，仓库会变得混乱。
需要区分的是：仓库里应该放的是写给人看的 CSS 源文件，压缩是构建阶段的事。压缩后的文件要么输出到构建目录，要么直接打包进上线产物，根本不需要提交到版本控制。
正确的处理流程
第一步：确认源文件在仓库中
仓库中保留的应该是带有缩进、换行和注释的原始 CSS。这是团队协作的“真身”，任何人都应该能直接阅读和修改。
第二步：把压缩配置为构建步骤
压缩不要手动执行，也不要顺手压完就提交。把它写进构建流程，让它在发布前自动运行。这样每次构建都会基于最新的源文件生成压缩产物，不需要人工干预。
第三步：指定压缩产物的输出位置
压缩后的文件输出到构建目录，或者直接打包进上线产物。构建目录通常不纳入版本控制，这样仓库里始终只有可读的源文件。
第四步：用钩子或流程约束提交内容
如果担心有人误提交压缩产物，可以用提交前钩子之类的工具，在提交前自动检查或处理，保证仓库里始终有未压缩的版本可供人阅读。
第五步：重要逻辑写在源文件里
很多 CSS 压缩工具默认会删除注释，即使你想在压缩文件里留点线索也留不下来。所以重要的、需要后人理解的逻辑，一定要写在源文件里，不要指望压缩后还能看到。
如果公司要求提交压缩文件怎么办
有些场景确实存在，比如某些静态托管平台，或者后端直接引用仓库里的文件。这种情况下也不是没有解法：
- 把压缩作为一个单独的构建步骤，在发布前执行，而不是改完代码顺手一压就提交
- 用提交前钩子之类的工具，在提交前自动处理，保证仓库里始终有未压缩的版本可供人阅读
- 由团队中有人牵头，把规范立起来，明确什么该提交、什么不该提交
方法总比困难多，关键是团队要有人把这个规范定下来。
常见问题
压缩后的 CSS 同事看不懂，是谁的问题？
不是同事的问题，也不是工具的问题。压缩代码本来就是给浏览器看的，不是给人看的。问题出在流程和规范上：团队没有约定好什么该提交、什么不该提交。
源文件和压缩文件应该同时放在仓库里吗？
不应该。仓库里放写给人看的源文件即可。压缩是构建阶段自动完成的事，压缩产物输出到构建目录或打包进上线产物，不需要提交到版本控制。
压缩工具会把注释删掉吗？
很多 CSS 压缩工具默认会删除注释。所以需要后人理解的逻辑，一定要写在源文件里，不要指望压缩后还能看到。
手动压缩后直接提交可以吗？
不建议。手动压缩容易覆盖原始文件，也容易让仓库里混入构建产物。更好的做法是把压缩写进构建流程，发布前自动执行。
团队该怎么避免这类问题？
核心就一条：源文件进仓库，压缩交给构建，不把压缩产物直接提交。把这条规范立起来，问题基本就解决了。