【资源存储方案】如何借助阿里云OSS优雅的解决图片存取问题

方案背景：

常规项目都会涉及到图片存储问题，图片资源的存取看似简单（放网站根目录就完事儿了–这是最低级方案，适合小项目），随着业务发展，场景多样，需求细化，不是瓶颈就是坑，头疼不是一点点；

比如：图片上传的时候允许上传5M大小的图片，但是在不同场景又需要不同规格尺寸大小及缩放比例的图片，如果全部采用原始图片链接下载，然后在前端进行缩放显示，这样会导致页面加载缓慢，特别是针对一些带图片的列表；（10张图片列表可能就是50M的数据，对用户来说浪费流量资源，对平台来说浪费额外带宽流量费用、对于当前页面而言加载缓慢到可能还没等到页面加载完成用户就已经关闭了）；

那么如何更加优雅、高效、一劳永逸解决解决后顾之忧呢？

解决方案：

如题，采用阿里云OSS存储服务，具体如何使用和落地，请查看《uniapp混合开发图片文件上传阿里云OSS最完美解决方案没有之一》

阿里云OSS图片操作原始文档：https://help.aliyun.com/document_detail/44688.html?spm=a2c4g.11186623.6.1677.5a3e6b29S9H6Cr

本文主要针对项目中遇到的一些实战问题进行举例：
项目采用Uniapp混合开发，其中H5端对需要上传的图片进行压缩裁剪比较困难，还存在浏览器兼容问题（走服务器进行图片压缩再转存OSS的方案暂不考虑）所以采用一种宽进严出的方案：

1、允许用户上传5M以内的图片；（OSS上传图片不产生流量费用）

2、由于前端没有对图片进行裁剪，所以在提取图片的时候借助OSS服务功能，通过连接对图片进行缩放控制后加载显示；
固定宽高，自动裁剪：一般的文章列表缩略，头像，任务列表都可以用这种方式处理，最后图片可能从几M降到几K，很简单的就避免了图片裁剪，压缩这两个步骤，而且后续显示加载也很轻快简洁高效；
https://xxx.com/task/xxx.png?x-oss-process=image/resize,m_fill,h_100,w_100

如果嫌链接后面的控制内容太臃肿：
https://xxx.com/task/xxx.png? x-oss-process=image/resize,m_fill,h_100,w_100
可以现在OSS后台设置样式这个样式，取名customstyle
简洁模式：https://xxx.com/task/xxx.png?!customstyle

2、有的地方需要等比例显示图片：按照原图的50%等比例缩放显示
https://xxx.com/task/xxx.png?x-oss-process=image/resize,p_50

小结：

本文主要解决前端H5绕开图片编辑裁剪压缩，简化开发过程，同时又能很好保证后续图片页面的加载速度和节约带宽成本，以一种解耦的方式独立存储图片，毫不担心后续的业务拓展，这里只是很粗浅的使用OSS的一个小小案例，更多功能请自行去了解。

有朋自远方来 虽远必诛，欢迎加微交流： 15249207822