西安健康码连续两次崩溃，在互联网上持续发酵，相关责任人被停了职，算是给了大家一个交代。不过一码通事件还没结束，有网友发现在2021年6月份一篇关于一码通项目的报道中，有夸大“技术难度”的嫌疑。
报道中提及：“为了确保系统运行更高效，他们将一张图片从1MB压缩到500KB，再从500KB优化到100KB。”并强调这件事的技术难度，技术人员连续两天两夜守在电脑前，最终攻克“难关”。
那么，西安健康码连崩两次，是否真的与“图片压缩技术”有关呢?
图片压缩技术有多难?
首先得先确定这张图片是否能被压缩，像健康码图片、广告图片等等，都属于可以被压缩的图片。手机屏幕大小有限，1MB的图片与100KB图片的显示效果没有什么区别。
图片压缩并不是什么很难的技术，将png转换成jpg，修改图片分辨率等等，都可以达到压缩图片的效果，不可能用两昼夜的时间去将一张1MB的图片优化成100KB。更何况在高频使用场景下，使用这么大的图片，本身产品设计上就存在缺陷。
问题的关键不在于压缩图片难度，而是开发应用程序使用的技术是否过关。
对此，网友提出了一个质疑：二维码是否在客户端生成?
要知道，二维码传递的信息都是一串字符，可能是网址、产品信息或者下载链接，服务端只需将这些字符传输给客户端，再由客户端生成二维码图片即可。这样一来大小就是1k级别的，根本不需要100KB。
如果采用在服务端生成二维码图片，再传输给客户端，这是一种很愚蠢的做法，因为会占用大量的带宽，同时使用人数一多， 很容易崩溃，一般开发人员都不会采用这种方式。鉴于该报道“两天两夜压缩图片”的报道，让许多内行的同学不得不怀疑，一码通是否会采用这种方式，如果是，连续崩溃两次也就不奇怪了。
网友经过对一码通的抓包，发现并没有出现这种情况。一码通确实采用的是前端生成二维码的方式。
显然，报道中提到的，将1MB优化到100KB的图片，并非二维码，而是广告、logo之类的图片。
一码通崩溃的原因
网友通过抓包还是发现了一码通现存的一些问题，比如在主页竟然出现了一张87KB的“快讯”图片，这张图片还仅仅是某篇文章的缩略图。
如果在上班高峰期，许多用户都是第一次打开一码通页面，并没有缓存在本地，服务器势必产生巨大的压力，很容易崩溃。
在这种高并发场景下，的确不应该存在这种大图片。另外一个因素，也可能是一码通本身的带宽不够，不足以支撑用码高峰期，市民的使用需求。
一码通到底是技术不过关，还是本身带宽不够，其实已经不重要。重要的是我们应该怎么吸取这两次的教训，避免再出现这种情况。毕竟疫情期间，无法查看健康码，不仅会影响出行，还会造成许多间接损失。
