这是一个创建于 1590 天前的主题，其中的信息可能已经有所发展或是发生改变。
请问大家在做含有图片这种业务的时候，图片是在选择完成后上传吗？我想了两种方案
1.选择完图片就上传，最终提交图片路径参数。该方案存在垃圾数据 2.选择完图片暂存，提交的时候图片、请求参数一起提交，后台处理返回
请问大家通常是如何处理，公司上 OSS 所以这块想正规下，我们是做电商的
还有 OSS 现在也没有批量上传的功能，大家都是自己写多线程还是循环传？
 |
1
takemeaway 2020-07-17 16:34:11 +08:00
不是还有 3 吗？ 直接存 base64
不过目前 1 是效率最高的，不用怕垃圾数据，硬盘不值钱。 |
 |
2
dswyzx 2020-07-17 16:42:08 +08:00
转 base64 是开玩笑么.
目前我一个做法是前台多图提交后台循环存 fastdfs,如果有 upload 失败则回滚删除已上传图片.返回前台失败,重新提交 考虑过一张一张传,处理垃圾数据太麻烦.于是作罢.用户麻烦两分钟,写代码少些两小时逻辑.就这样吧.反正失败现在还没遇到过 |
 |
3
belin520 2020-07-17 16:42:41 +08:00
上传、存储服务跟你的业务逻辑应该是完全解耦的
上传到 OSS 后返回唯一资源的 key，然后入业务逻辑的库 垃圾数据能有多少，怎么样定义垃圾数据呢？ |
 |
4
Lindp OP @takemeaway base64 在这种场合不适合吧，如果图片太多，请求体也太大了
|
|
5
Lindp OP |
 |
6
qwertyzzz 2020-07-17 16:56:26 +08:00
图片库吧 就是一个项目一个图片库 上传图片都是在图片库里 别的界面上传图片都是到这里面选择的，没有的上传
|
 |
7
Olive 2020-07-17 16:57:34 +08:00
我前几天也在考虑这个图怎么传。
后来我用的方法一 然后写个定时任务将 图片表里的 没有关联 id 图全删除。 感觉这么方法挺笨的 哈哈 ，想学学看大家有什么好方法。 |
 |
8
sm0king 2020-07-17 16:58:50 +08:00
1
|
|
10
Lindp OP @qwertyzzz 嗯，这个倒是一种方法，类似微信公众号的那种，图片都存起来然后其他地方选择。不过是不是业务量比较大才能用这种方案啊，小项目或发展中的项目会不会太麻烦了？
|
 |
11
tmrQAQ 2020-07-17 17:07:00 +08:00
1
硬盘不值钱 |
 |
12
MrTreasure 2020-07-17 17:17:16 +08:00
选择完图片后，本地预览。确定了再上传 OSS，然后再返回给后端地址
|
 |
13
renmu123 2020-07-17 17:21:17 +08:00 via Android
我也选择 1，体验会比 2 好不少，多不了什么硬盘量
|
 |
14
ychost 2020-07-17 17:41:09 +08:00
1 体验比较好，图片能有多大，定期去对比图片删除就好了
|
 |
16
frandy 2020-07-17 17:50:58 +08:00
倾向方案 1：怎么会存在垃圾数据，上传完了之后，用户如果对图片需要修改，那把原来的图删除之后在上传咯。前端多调用一个删除图片接口。
|
|
17
frandy 2020-07-17 17:55:09 +08:00
[怕用户选了五六张图片，最后没保存取消了] 按取消的时候，判断是否有图片，有的话调用删除图片再取消。至少能缓解一点量。我实际项目中是不会删用户的图片的。
|
 |
18
ChefIsAwesome 2020-07-17 18:12:15 +08:00 via Android
一起传也不是一次性全传过去，而是一张张单独传的。只要有一张失败，或者传完之后，调后端接口的时候失败，前面传成功的也变成垃圾数据了。
接口挂了，用户网络出问题了，不小心关了页面，传的太久不想传了，各种失败的可能性。深究起来没完没了。 楼主你就不用考虑那么多了，只要交互设计的合理，两种方案都行。 |
 |
20
GuangXiN 2020-07-17 22:59:19 +08:00 via Android
我公司用的方案一，垃圾数据定期 GC 。
|
 |
21
Mystery0 2020-07-17 23:43:08 +08:00 via Android  1
@Lindp 我司的就是上传和保存分开，上传成功之后返回资源 id，保存的时候提交资源 id，后端确认资源使用，然后另跑一个服务定期删除未确认使用的资源
|
 |
22
lxml 2020-07-17 23:55:29 +08:00
当然是 1，其实都不用怎么去做删除，硬盘不值钱，流量值钱，做好监控别被人当图链用就好了
|
 |
23
szdubinbin 2020-07-18 00:11:26 +08:00
其实批量一次过传是最科学的，如果一张一张，那用户感觉前面有张不好，那还得做个换或者删掉的交互，麻烦。
目前 cos 是循环去伪装批量。 https://juejin.im/post/5dff8a26e51d4558105420ed 我今天看到这个，感觉很多东西不错，续点续传，分片上传，控制并发，可以参考一些操作。 |
 |
24
lagoon 2020-07-18 00:17:48 +08:00 via iPhone
啊？发现更多人选了选完就传。
但，选一张转个圈体验太不友好了吧。 不转圈，用户以为传完退出也挺麻烦。 而且从界面展示来看，给用户的感觉是选只是选，最终的传是点击发布完成的（如果界面是类似朋友圈的那种交互）。 我觉得选了就传，从道德上来说也微妙吧。 虽然这年头的开发基本已经不讲道德了。 |
 |
26
aloyuu 2020-07-18 09:48:13 +08:00 via Android
不好意思圈错了
4 返回图片信息，不是 id |
|
27
aloyuu 2020-07-18 09:48:59 +08:00 via Android
key
|
 |
28
lovecy 2020-07-18 10:15:58 +08:00
@lagoon 可以有个队列，选完就加入队列，最终用户点确定时，再根据队列里未上传的给上传进度显示。不过这个隐私道德也是一方面，不讲道德或是不怕被人扒出来就无所谓
|
 |
29
skypyb 2020-07-18 12:39:57 +08:00
肯定是 1, 真怕垃圾数据， 可以代码里做可达性分析然后 GC
|
 |
30
KingPL 2020-07-18 13:25:54 +08:00
可以传完文件，一个文件一条记录，返回 ids ；表单提交文件 id 上来，再把文件记录对应 id 的业务类型、绑定的 id 更新就好了，设置清理无用文件规则；里面还需要些鉴权手段
|
|
31
Lindp OP @ChefIsAwesome
@frandy @Mystery0 @lxml @szdubinbin @lagoon @skypyb @KingPL 感谢大家，认真听取了各方面的意见，我还是采用方案 1 吧 |
 |
32
MarioLuo 2020-07-18 13:46:05 +08:00 via Android
感觉有两种方式，1.伪批量提交，用户点击表单前调用额外的上传接口上传图片，成功后再提交表单，可以减少垃圾图片数量，2.在图片上传接口记录上传图片信息,
|
|
33
MarioLuo 2020-07-18 13:50:55 +08:00 via Android 1
包括(id, url, status, creatTime), 并返回 id+url, 表单上传根据图片 id+url 修改图片信息状态，可根据该图片表清除垃圾数据，人工或定时程序
|
 |
34
pinews 2020-07-18 15:24:22 +08:00
微博上传图片，根本就不关心你是谁上传的。
|
 |
35
hallDrawnel 2020-07-18 17:15:54 +08:00
垃圾数据应该可以不管，储存压力大的话可以定期 GC 。
|
 |
36
realpg 2020-07-18 22:01:51 +08:00
第三方存储上传的话 方案 1
webserver 本机存储的话 方案 1 和方案 2 看情况 如果是编辑器类上传，上传了可能没用的话，或者盗窃你资源当图床的话，在上传时候加上相关参数，在哪个资源下上传的，然后同时在编辑器内容存档后 进行一次遍历引用了多少资源做记录 这样方便清理和后续整理。 |
Select Language