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

• 資深大佬 : 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 。

• 資深大佬 : Mystery0

  @Lindp 我司的就是上传和保存分开，上传成功之后返回资源 id，保存的时候提交资源 id，后端确认资源使用，然后另跑一个服务定期删除未确认使用的资源

• 資深大佬 : lxml

  当然是 1，其实都不用怎么去做删除，硬盘不值钱，流量值钱，做好监控别被人当图链用就好了

• 資深大佬 : szdubinbin

  其实批量一次过传是最科学的，如果一张一张，那用户感觉前面有张不好，那还得做个换或者删掉的交互，麻烦。
  目前 cos 是循环去伪装批量。
  https://juejin.im/post/5dff8a26e51d4558105420ed

  我今天看到这个，感觉很多东西不错，续点续传，分片上传，控制并发，可以参考一些操作。

• 資深大佬 : lagoon

  啊？发现更多人选了选完就传。

  但，选一张转个圈体验太不友好了吧。
  不转圈，用户以为传完退出也挺麻烦。

  而且从界面展示来看，给用户的感觉是选只是选，最终的传是点击发布完成的（如果界面是类似朋友圈的那种交互）。
  我觉得选了就传，从道德上来说也微妙吧。

  虽然这年头的开发基本已经不讲道德了。

• 資深大佬 : aloyuu

  @Lindp 图片表，1 入库，2 上传，3update，4 返回 id

  内容表，提交后关联 id

• 資深大佬 : aloyuu

  不好意思圈错了

  4 返回图片信息，不是 id

• 資深大佬 : aloyuu

  key

• 資深大佬 : lovecy

  @lagoon 可以有个队列，选完就加入队列，最终用户点确定时，再根据队列里未上传的给上传进度显示。不过这个隐私道德也是一方面，不讲道德或是不怕被人扒出来就无所谓

• 資深大佬 : skypyb

  肯定是 1, 真怕垃圾数据， 可以代码里做可达性分析然后 GC

• 資深大佬 : KingPL

  可以传完文件，一个文件一条记录，返回 ids ；表单提交文件 id 上来，再把文件记录对应 id 的业务类型、绑定的 id 更新就好了，设置清理无用文件规则；里面还需要些鉴权手段

• 主 資深大佬 : Lindp

  @ChefIsAwesome
  @frandy
  @Mystery0
  @lxml
  @szdubinbin
  @lagoon
  @skypyb
  @KingPL

  感谢大家，认真听取了各方面的意见，我还是采用方案 1 吧

• 資深大佬 : MarioLuo

  感觉有两种方式，1.伪批量提交，用户点击表单前调用额外的上传接口上传图片，成功后再提交表单，可以减少垃圾图片数量，2.在图片上传接口记录上传图片信息,

• 資深大佬 : MarioLuo

  包括(id, url, status, creatTime), 并返回 id+url, 表单上传根据图片 id+url 修改图片信息状态，可根据该图片表清除垃圾数据，人工或定时程序

• 資深大佬 : pinews

  微博上传图片，根本就不关心你是谁上传的。

• 資深大佬 : hallDrawnel

  垃圾数据应该可以不管，储存压力大的话可以定期 GC 。

• 資深大佬 : realpg

  第三方存储上传的话 方案 1

  webserver 本机存储的话 方案 1 和方案 2 看情况

  如果是编辑器类上传，上传了可能没用的话，或者盗窃你资源当图床的话，在上传时候加上相关参数，在哪个资源下上传的，然后同时在编辑器内容存档后 进行一次遍历引用了多少资源做记录

  这样方便清理和后续整理。