关于图片上传的疑问，该选一张传一张还是提交一起传？

[Lindp]

请问大家在做含有图片这种业务的时候，图片是在选择完成后上传吗？我想了两种方案

1.选择完图片就上传，最终提交图片路径参数。该方案存在垃圾数据 2.选择完图片暂存，提交的时候图片、请求参数一起提交，后台处理返回

请问大家通常是如何处理，公司上 OSS 所以这块想正规下，我们是做电商的

还有 OSS 现在也没有批量上传的功能，大家都是自己写多线程还是循环传？

[takemeaway]

不是还有 3 吗？ 直接存 base64

不过目前 1 是效率最高的，不用怕垃圾数据，硬盘不值钱。

[dswyzx]

转 base64 是开玩笑么.
目前我一个做法是前台多图提交后台循环存 fastdfs,如果有 upload 失败则回滚删除已上传图片.返回前台失败,重新提交
考虑过一张一张传,处理垃圾数据太麻烦.于是作罢.用户麻烦两分钟,写代码少些两小时逻辑.就这样吧.反正失败现在还没遇到过

[belin520]

上传、存储服务跟你的业务逻辑应该是完全解耦的
上传到 OSS 后返回唯一资源的 key，然后入业务逻辑的库

垃圾数据能有多少，怎么样定义垃圾数据呢？

[Lindp]

@takemeaway base64 在这种场合不适合吧，如果图片太多，请求体也太大了

[Lindp]

@dswyzx
@belin520

考虑方案 2 的初衷就是怕用户选了五六张图片，最后没保存取消了，结果图片都已经上传到服务器了，这部分图应该都算是垃圾数据吧

[qwertyzzz]

图片库吧 就是一个项目一个图片库 上传图片都是在图片库里 别的界面上传图片都是到这里面选择的，没有的上传

[Olive]

我前几天也在考虑这个图怎么传。
后来我用的方法一
然后写个定时任务将 图片表里的 没有关联 id 图全删除。

感觉这么方法挺笨的 哈哈 ，想学学看大家有什么好方法。

[sm0king]

1

[Lindp]

@Olive 你是有个图片库这种的吗？然后迭代所有图片？这个效率感觉是个问题 数据越多越麻烦

[Lindp]

@qwertyzzz 嗯，这个倒是一种方法，类似微信公众号的那种，图片都存起来然后其他地方选择。不过是不是业务量比较大才能用这种方案啊，小项目或发展中的项目会不会太麻烦了？

[tmrQAQ]

1
硬盘不值钱

[MrTreasure]

选择完图片后，本地预览。确定了再上传 OSS，然后再返回给后端地址

[renmu123]

我也选择 1，体验会比 2 好不少，多不了什么硬盘量

[ychost]

1 体验比较好，图片能有多大，定期去对比图片删除就好了

[laoyur]

@Olive 你这 ID 差点以为是老板娘

[frandy]

倾向方案 1：怎么会存在垃圾数据，上传完了之后，用户如果对图片需要修改，那把原来的图删除之后在上传咯。前端多调用一个删除图片接口。

[frandy]

[怕用户选了五六张图片，最后没保存取消了] 按取消的时候，判断是否有图片，有的话调用删除图片再取消。至少能缓解一点量。我实际项目中是不会删用户的图片的。

[ChefIsAwesome]

一起传也不是一次性全传过去，而是一张张单独传的。只要有一张失败，或者传完之后，调后端接口的时候失败，前面传成功的也变成垃圾数据了。
接口挂了，用户网络出问题了，不小心关了页面，传的太久不想传了，各种失败的可能性。深究起来没完没了。
楼主你就不用考虑那么多了，只要交互设计的合理，两种方案都行。

[GuangXiN]

@frandy 如果用户不按取消直接关闭页面呢？

[GuangXiN]

我公司用的方案一，垃圾数据定期 GC 。