那天下午我正蹲在工位上摸鱼，突然群里炸了锅——GitHub打不开了。一开始以为是公司网络抽风，结果一看推特，全球开发者都在哀嚎。有人开玩笑说，这可能是人类历史上生产力下降最猛的一天。我一开始还跟着乐，直到我发现自己的项目正好那天要上线。
事情是这样的，我手头有个小项目，前端资源打包完差不多有3MB的JS代码。平时部署都走CI，结果GitHub一崩，CI跑不了，我只能手动把本地构建好的文件传到服务器。传的时候我还纳闷，怎么这次上传这么慢，进度条跟蜗牛爬似的。等了快十分钟，终于传完了，结果打开页面一看，白屏。
我以为是服务器问题，查了半天日志，最后发现是文件传输过程中出了点岔子，代码里混进了一些奇怪的字符。当时我就懵了，离上线只剩半小时，重新构建来不及，回滚也没备份。那一刻我才真正意识到，如果平时有把代码压缩的习惯，文件小一半，传输出错的概率也会低很多，说不定就能赶上了。
后来我是怎么解决的呢？我翻出了之前随手存的一个在线工具，叫JS格式化压缩。这玩意儿平时我根本不用，觉得代码能跑就行，压不压缩无所谓。但那天我死马当活马医，把本地那份3MB的源码扔进去，点了压缩，几秒钟后出来一个1.2MB的文件。我赶紧传上去，替换掉那个坏掉的文件，刷新页面，好了。
那一刻我盯着屏幕，心里五味杂陈。你说代码压缩这事儿，平时看着不起眼，甚至有点多余——现在网速这么快，带宽这么便宜，谁还在乎那点体积？可一旦遇到突发情况，比如GitHub崩了、CI挂了、网络抖了，你才会发现，小体积就是硬道理。它不光省流量，还能减少传输时间，降低出错概率，甚至在关键时刻救你一命。
而且说实话，代码压缩的好处远不止这些。你压缩完的代码，别人想偷看逻辑也费劲，虽然不能算加密，但至少能挡一挡那些直接右键查看源码的。另外，压缩后的文件加载更快，用户体验也好，尤其是移动端，少几百KB可能就少白屏一秒。以前我觉得这些都是小事，但经历过那次之后，我彻底改了。
现在我的习惯是，每次构建完都顺手用JS格式化压缩过一遍，然后再部署。不费什么事，但心里踏实。你永远不知道明天和意外哪个先来，GitHub会崩，CI会挂，网络会抖，但一个压缩好的小文件，永远是你最稳的后备方案。
所以啊，别等到出事才后悔。平时多压一压，关键时刻能救命。这不是什么高深的技术，就是一个简单的习惯，但往往就是这种小习惯，决定了你是手忙脚乱还是从容应对。