软件更新就像超市换商品,明明只变了几件,真的有必要把几千件都重新搬一遍?

软件更新就像超市换商品，明明只变了几件，真的有必要把几千件都重新搬一遍？

我最近做项目时，碰到了一件很“笨”的事情。

软件明明只改了一点点，比如网页上一个按钮、一张图片、几个文字。

结果每次更新，却都要把整个程序重新打包、重新上传、重新解压、重新切换。

一共87MB。

可能真正改掉的东西，只有1MB多一点。

就像一家超市，今天只卖掉了30件商品。

正常人都会觉得：缺什么，补什么不就行了？

可如果按照我们以前的软件更新方式，做法却相当于：把超市里剩下的几千件商品全部拉走，然后再重新把整个超市的货运回来一遍。

听起来是不是有点离谱？可很多软件系统，每次更新，其实就在干差不多的事。

01一家超市，只缺了几件货

假设你家附近有一家超市。

里面有饮料、零食、洗衣液、纸巾、米面粮油，一共几千种东西。

晚上盘点的时候发现：今天只少了30件商品。

第二天补货，最合理的办法当然是：少了可乐，就补可乐。少了纸巾，就补纸巾。新上了一种牛奶，就把新牛奶送过来。其他没动过的商品，继续老老实实放在货架上。

谁也不会说：“今天既然要补货，那就把整个超市的商品全部拉回仓库，再全部送回来一遍。”

因为大家都知道，这样做太浪费。

浪费车。浪费油。浪费时间。还得腾地方重新堆货。

可软件更新，经常就是这样。

02我以前每次更新，都像“整个超市重新进货”

我之前的项目，每次更新的时候，不管改动大小，都要重新上传一个完整的软件包。这个包大约87MB。哪怕我只是改了网页上的一个按钮。

流程还是一样：重新打包→重新上传→重新解压→重新切换→重新检查。

网络快的时候，还好。网络慢一点，就得等。

而且最让我觉得不划算的是：87MB里面，大部分东西其实根本没变。

明明货架上99%的商品都还好好的，却因为换了几个商品，把整个超市又重新进了一遍货。

所以我开始想：能不能换一种办法？以后到底改了什么，就只传什么。没变的，一律不动。

03后来，我把87MB变成了1.4MB

后来我真做了一套这样的办法。

更新之前，先把“旧版本”和“新版本”对一遍。就像超市每天晚上盘点：哪些货没变？哪些货少了？哪些货换了包装？哪些是新上架的？

▲ 先对一遍：哪些变了，哪些没变

把这些变化找出来以后，只把真正发生变化的东西送过去。其他没变的文件，全部留在原地。

有一次实测：原来需要上传87MB。改成这种方式以后，只需要上传1.4MB左右。相当于少传了98%的东西。

这就像原来需要一辆大货车，现在一个小面包车就够了。

04但“只补缺的货”，有一个前提

听起来很简单：缺什么补什么。但这里有一个很重要的问题。

你得先确认：现在货架上放的，真的是你以为的那一批货。

比如仓库准备了一箱新包装的牛奶。它本来是准备给“昨天那批货”补进去的。结果送到店里一看：这家店现在放的，居然已经是更早的另一批货。那就不能硬往里面塞。因为新货和旧货可能对不上。

▲ 新货到了，先贴的标签对一对——对不上就退回，不硬塞进货架

所以，我给每次更新都加了一张“标签”。这张标签会写清楚：这批新东西，是在什么旧版本上改出来的。

如果到了服务器上一对：对不上。那就停止更新。宁可不更新，也不能硬塞。

这和超市补货是一个道理。仓库发货之前，总得先确认：这是发给哪家店的。是什么批次。数量对不对。

05新货不能一到，就直接往货架上扔

以前的软件更新还有一个问题。新东西来了，直接往原来的地方覆盖。这就有点像：超市营业的时候，一边卖货，一边把货架拆了重新摆。

最麻烦的是：如果摆到一半出了问题怎么办？旧的已经拆了，新的又没摆完。顾客进来一看，一片混乱。

所以现在我换了一个办法：旧货架先不动。

新货架摆好再指过去，旧的先别扔

新版本先放在旁边一个完整的新区域里。所有东西都摆好。检查完。确认没问题。

最后只做一件事：把顾客入口指向新的那一边。

如果新版本真有问题呢？再把入口指回旧版本。就这么简单。旧的那一套，一直还在那里，没有被破坏。所以回去特别快。

为什么“旧的那套”一定不能急着扔

为什么旧的那一套不能马上扔？

这有点像超市换收银系统。

假设一家超市准备启用一套新的收银系统。

比较稳妥的做法，不是今天晚上把旧系统全部拆掉，明天一早直接赌新系统一定没问题。

而是先把新系统准备好，商品、价格、支付这些功能全部检查一遍。

确认没问题以后，再让顾客开始走新系统。

但旧系统先别急着删。

因为真正营业以后，才可能发现一些测试时没发现的问题：

有的商品扫不出来，

有的优惠算错了，

有的付款方式突然不能用了。

这时候，如果旧系统还在，就可以马上切回去，先保证超市正常营业，再慢慢查新系统的问题。

软件更新也是一样。

新版本上线以后，旧版本暂时留着，并不是因为觉得新版本一定会出问题。

而是为了给自己留一条退路。

新版本没问题，再慢慢清理旧版本。

新版本真出了问题，先切回旧版本，让系统恢复正常。

最麻烦的从来不是“新版本出了问题”。而是：新版本出了问题以后，才发现旧版本也已经被删掉了。

很多事故，不是因为新版本出问题。而是因为：新版本出了问题以后，旧版本也已经没了。那才是真的麻烦。

06当然，不是什么情况都适合“只补一点”

这里也不能为了省事，什么都做成小更新。有些变化，就像超市重新装修：

货架位置全改了。收银系统换了。仓库规则改了。门禁也换了。

这时候就不能再说：“我今天只补两箱饮料。”因为它已经不是补货问题了。整个店都变了。

软件也一样：

只是网页上的文字、图片、按钮这些小变化——通常适合只更新变动的部分。

但如果动了后台程序、数据库、登录规则、系统配置这些核心东西——就应该老老实实走完整更新。

不要为了省几分钟，硬省。能省的时候省。不该省的时候，别赌。

07我现在判断要不要“小更新”，只看一件事

我不会先看文件有多大。而是先问：这次改动，会不会影响整个系统？

如果不会，那就只更新变化的部分。

如果会，那就走完整更新。

这就像超市：只是少了几箱水，补货就行。如果准备把整个超市重新装修，那就不是补货能解决的事了。

这个判断，比“文件大不大”更重要。

后来我才发现，省下来的不只是流量

一开始，我只是嫌每次上传87MB太慢。

后来真正用起来以后，我才发现，它省下来的其实不只是网络流量。

还省时间。还省服务器空间。更新更快。出问题更容易退回。

而且因为每次动的东西更少，出错的地方也更容易找。

以前一次更新像搬一整车货。出问题以后还得想：到底哪一箱出了问题？现在一次只送几箱。出了问题，排查范围自然就小很多。

很多系统，其实不是做不到，而是以前没觉得有必要

项目小的时候，87MB好像也没什么。传一次就传一次。十分钟也能等。所以没人太在意。

可当更新越来越频繁以后，问题就慢慢出来了。一天更新一次。一周更新几次。甚至一天改好几次。

这时候你就会发现：每次为了几件变化，把全部内容重新传一遍，真的很浪费。

很多技术改进，其实不是为了“炫技”。它只是把一件本来很笨的事情，换成一种更符合常识的做法。

就像超市补货一样。

缺什么，补什么。没变的，不要动。新货没验好，旧货别急着扔。真有问题，马上退回原来的那一套。

说到底，就是这么简单。

写在最后

以前每次更新，我都像是在把整个超市重新进一遍货。

后来我才意识到：其实根本没必要。

如果今天只换了3件商品，那就只送这3件。其他几千件货，让它们老老实实待在原来的货架上。

我上一次实测，完整更新需要大约87MB，只更新变化部分以后，只剩1.4MB左右。

不是因为用了什么特别神奇的技术。只是终于不再做那件最笨的事：

明明只缺几件货，却每次把整个超市重新进一遍。

如果你也在做网站、系统或者经常更新的软件项目，可以问自己一个问题：

我每次更新，真的需要把所有东西重新传一遍吗？也许，你缺的不是更快的网络。而只是一次更聪明的“补货”。