[广州|结业弟子]JAVA-张明顺|2019年11月28日的日报-技能树.IT修真院

发表于： 2019-11-28 23:04:21

1 935

今天完成的事情：

昨天因为和另外两个组员争了下上传图片接口的问题。我妥协了，但是我认为我是对的。

早上被老大教育了，

对方说少调一个接口，防止上传无用图片。对不对，对。那我呢？我一直觉得他们的做法不对。但是对方给了我说法。我又说不出我对的地方，凭什么不按照对方的做。

早上我仔细的思考了下，我是对的。但不是说我是对的，就完了，你凭什么你说的是对的。理由呢，证据呢？

所以我花了点时间……呃，一早上，测试了下并把两种方式的对比列了下。他们那种方式的不好的地方在哪里。

上传图片方案对比

base64

优点：

1.不保存，不进行上传。

2.前端请求次数少

缺点：

1.转换要消耗时间，带宽与性能。

2.转换后的base64比原图大，约大了30%

3.不能异步，最后保存数据时，如果图片过大，整个请求过程需要很长时间。使接口稳定性降低。会有卡在那里的感觉。

4.在每个上传图片接口都要增加处理上传图片的代码。造成接口臃肿，接口功能不单一，

5.图片传输过程不可控。

multipartFile

优点：

1.添加动画点击上传后图片可以看上传情况。又可以继续编辑其他参数，形成异步 ，可控。

2.所有文件上传使用的都是一个接口，复用性

3.可以使用授权第三方上传的方式，用户直接上传图片到第三方，不占用服务器带宽与占用服务器性能。

缺点：

1.如果上传图片后当前数据不保存，浪费第三方空间。（可以清除无用图片，所以不算缺点）

2.要多请求一次接口。（新增操作，又用的是异步，多请求一次上传接口有什么问题，又不是查询要求那么高，少了传输图片至服务器，还给服务器省资源）

小结：网上多种说法，base64适合的地方是小图。现在网站连头像都可以保存高清大图，更何况用在banner上。复盘定的图片最大为5M。为了这一个功能，前端是少调了一次接口，但是后端要在每个接口增加对应代码，耦合度增加，接口请求时间增加，稳定性减少。大大增加出错的机率，我测试了一张5M图，变成7.8M左右，转换的时候还在那卡了，我还以为死机了。所以，banner新增接口上传不适合用base64。

总结的不一定很好，但是大部分说法还是没问题的。上传图片，就是单独的一个接口！

明天计划的事情：

订单后台还有一个详细查询，没难度。可能要改下接参方式

遇到的问题：

前端，和另外两个组员接参用的json，我用的x-www-from-urlencoded。。。这个确实没考虑到当初没统一接参格式，他们统一的。。汗。

收获：