前两天在技术群里看到一个吐槽帖，发帖的人说项目上线前用工具把CSS压缩了，结果第二天同事打开样式文件一看，满屏全是挤成一团的字符，当场就炸了：“这谁写的？是人能看的吗？”发帖人委屈巴巴地说，压缩是构建流程的一部分，自己也没办法。
这事儿其实挺典型的，几乎每个前端团队都吵过。今天咱们就掰扯掰扯，CSS压缩后同事看不懂，这锅到底该谁来背？
先说说CSS压缩是干嘛的。说白了，就是把代码里的空格、换行、注释全干掉，变量名能短就短，目的是让文件体积变小，网页加载更快。这本身没毛病，线上环境追求性能，压缩是标配操作。但问题出在，很多人把压缩后的文件直接提交到了代码仓库，甚至覆盖了原始文件。同事一拉代码，看到的全是像“a{b:c;d:e}”这样的天书，能不懵吗？
那这锅该甩给谁？有人说是压缩工具的锅，怪它太“暴力”。但工具是无辜的，它就是个执行命令的程序，你让它压缩，它可不就往死里压吗？你拿菜刀切菜切到手，总不能怪菜刀太锋利吧。
也有人说是同事的锅，觉得前端工程师看不懂压缩代码是基本功不行。这话有点站着说话不腰疼。压缩后的代码本来就是给浏览器看的，不是给人看的。就像你把一篇小说翻译成摩斯密码发给朋友，朋友看不懂，你能怪他语文没学好？正常人的阅读习惯是看有缩进、有注释、有换行的代码，压缩代码完全反人类。要求同事硬啃压缩代码，那不是锻炼能力，那是折磨人。
我觉得，真正的锅，得甩给流程和规范。说白了，就是团队没有约定好“什么该提交，什么不该提交”。正规的做法是，源代码（就是写给人看的那个CSS）老老实实放在仓库里，压缩是构建阶段自动完成的事儿，压缩后的文件要么输出到dist目录，要么直接打包进上线产物里，根本不需要提交到版本控制。但很多团队图省事，或者一开始没想清楚，直接把压缩文件也提交了，于是问题就来了。
有人可能会说，那要是公司就要求把压缩文件提交呢？比如某些静态托管平台，或者后端直接引用仓库里的文件。这种情况确实存在，但也不是没解。你可以把压缩作为一个单独的构建步骤，在发布前执行，而不是改完代码顺手一压就提交。或者用pre-commit钩子之类的工具，在提交前自动处理，保证仓库里始终有未压缩的版本可供人阅读。方法总比困难多，关键是团队得有人牵头把这个规范立起来。
还有个容易被忽略的点，就是代码注释。很多CSS压缩工具默认会把注释也删掉，这就导致即使你想在压缩文件里留点线索，也留不下来。所以，重要的、需要后人理解的逻辑，一定要写在源文件里，而且别指望压缩后还能看到。这也是为什么保留源文件那么重要——它是团队协作的“真身”。
说到底，CSS压缩本身不是坏事儿，坏的是没有配套的管理习惯。同事看不懂，不是因为他菜，也不是因为工具蠢，而是工作流里缺了一环。这事儿就像做饭，菜刀是好菜刀，但你非要把菜剁成泥端上桌，客人说不好看，你能怪菜刀吗？
所以，别再为这事儿吵架了。下次再遇到，大大方方承认是流程没定好，然后赶紧把规范补上：源文件进仓库，压缩交给构建，谁也别手贱把压缩产物直接提交。要是早就这么干，哪还有这锅可背？说白了，技术问题背后，往往是管理问题。你说是不是？