一个页面要多人获取头像， base64 传输 body 巨大，有什么好办法吗

[fyxtc]

差不多 60 个人头像，base64 已经是压缩图片后编码的 b64 了，可是字符串放在 body 里还是巨大，差不多还有 4MB ，而且这个页面是会频繁刷新的，有成员变动就自动去获取新数据，几秒就干一个 4MB ，吃不消啊

[okakuyang]

可以用不同的压缩算法压缩响应，如果可以用二进制流传输会比 base64 小一点。base64 会膨胀一点。

[adoal]

你是说把所有人的头像图片作为整体来传输，有人的改变了就把 60 个人头像的这个整体重传一边？这不是给自己找麻烦嘛。

[blankmiss]

6 啊 这种设计真的无力吐槽

[huangzhiyia]

建议接口改成 api/(unique_id).jpg

[cvbnt]

oss ？

[nkidgm]

其实用 base64 传输体积更大了，直接传输还省点流量。。。

[ruoxie]

正常操作不是图片存 oss ，后端存图片地址？

[xiangyuecn]

4MB/4*3=3MB （ Base64 导致增大 1MB ）
3MB/60=50KB （ 50KB 一张图，应该还能再压缩一下到 10-20KB 一张头像）

所以，请使用 url ，依靠浏览器缓存，除了第一次 后面随便你变动，老图都没有流量消耗

[darkengine]

这实现方案是谁定的。。。

[zephyru]

读了好几遍也没弄明白这个场景为啥要用 base64..用 oss 上 cdn 吧，不行的话，前端手动实现一个缓存？感觉好像也没啥用..后端，把 base64 写成文件，提供 url 让前端用，作用估计也有限..主要不知道这里的，吃不消体现在哪里，页面卡？还是接口返回慢？ 4mb 说大不大，页面我觉得很少会因为这个卡的..

[dayeye2006199]

图像存在了数据库里面？

[fyxtc]

@zephyru 页面在取到数据前会转 loading ，数据越大 loading 越久，之前有实现过 url ，体验不好，有的图片如果加载慢就是空白放着，还有可能有的图片永远加载不出来，前端没法缓存，因为有可能随机几秒到几分钟之后 60 个全变的。前端是不知道哪些是变的哪些是不变的。

[Zwying]

返回地址吧，base64 不适合

[vileer]

@fyxtc img 标签正解，直连浏览器有缓存，后面上 cdn 也可以加速，不用回源站

[jazzg62]

img 标签会有 onload 和 onerror 进度事件，监听就能知道哪些加载好了，哪些还在加载中，哪些加载错误
@fyxtc

[superares]

应该是为了解决浏览器的问题：同域名并发请求数少，同时加载 60 个图片会加载很久

[okakuyang]

你这个问题可以让前端去解决，因为你这需求以为是保密数据需要解密从数据库读取。如果不是的话返回地址和版本号给前端，从前端去判断哪些需要更新，缓存图片的方法很多种，如果不想缓存就给链接添加一些参数，图片加载不出来就让前端优化加载逻辑。

[fyxtc]

@okakuyang 感谢大家，我修改一下