根据 Discourse 官方的博客说明： Faster (and smaller) uploads in Discourse with Rust, WebAssembly and MozJPEG
Discourse 对图片上传进行了比较大的优化，主要是采取了 HTML5 的图片上传预处理技术。
上面是这次更新的处理逻辑，主要是为了方便用户在上传手机图片的时候进行预压缩。
这是因为手机图片的大小通常都比较大，如果使用原图上传的话，将会导致大量占据存储空间，其实也是没有必要的。
根据官方博客中的内容显示，图片大小被压缩得比较小，但是图片效果却没有大量改变。
同时因为图片大小的变化，也会提升站点的传输速度。
压缩算法是在客户端进行的，只要是支持 HTML5 的浏览器都可以使用，因此不会额外增加服务器处理资源。
不，这个问题值得重新来讨论，我刚才在我的论坛上发布了一个大概5M的高清图片，这个图片是一个长图，而不是一个正常比例的图片的带有大量元数据的图
在上传之后我发现论坛对该图片进行了压缩，压缩到了只有61KB，然后点开之后图片里的信息几乎全部失去，无法查看，和打了重度马赛克一样
即使我点开图片，点击查看原始图片，发现也是经过压缩后的，依然完全不可见详细信息
我想讨论讨论这种情况该如何办呢？
测试帖子：
感觉你的图片的问题在于这个图片是横向长图。
如果是纵向长图可能就不会压缩得那么过了。
我找了一个纵向长图，大小 629kb。
不管是不是原图，在图片上传的时候就已经处理了。
同时，后端有几个配置。
包括是不是启用客户端媒体图片优化，可以考虑把这个选项取消选择。
请参考下官方的这个帖子：Help me understand image compression - Support - Discourse Meta
图片触发这个功能的条件只有区区的 524Kb。
对，我刚看了下，默认情况下，后台的限制是 宽度 超过1920的图片，将会被自动压缩和裁切到 最大宽度 为 1920 的一个情况
可能确实是考虑到在网络环境下频繁传输这种高清的大文件会持续的占用内存和带宽，增加访问速度，代价就是如果上传宽度超过 1902 的图片，画质将会被压缩的非常狠，但高度却没有这个限制。
这个功能的主要目的应该还是为了适应手机上的向下滑动。
类似微信的长图功能，更多的还是做的纵向长图。
如果是横向长图的话，图片就会被按照宽度进行处理，如果不希望用，可以先禁用这个功能把。
对网络来说，这样能降低网络数据传输，毕竟传输一个 5MB 的图片还是蛮费劲的。
我刚才去实测了一下，确实是只限制 宽度，我把那张图片转换成竖向，然后再次上传， 发现原来的“高度”并不会压缩，还是1080，原来的“宽度”也不会被压缩，还是15001：
这个542kb是触发压缩算法，而不是我刚说的图片裁切，我那个原图是4.9M，当触发这个压缩算法之后，在15001*1080分辨率不变的情况下，图片大小被压缩到了2.2M，
只有下面的那个1902才是图片被裁切的罪魁祸首 
我倒觉得，在目前手机为大范围使用的情况下。
作为信息的发布者，可能还是更多的需要考虑手机用户的使用，长图可能最好还是使用纵向。
估计随着后面的发展，横向长图慢慢的都会消失了。
是这样的，今天只是无意中发现了这个“鸡肋”的一个操作，吐槽一下只限制宽度，哈哈哈哈
微博也是这么干的，所以很多作者只能把横长图转成竖长图
