本人亲测有效，如果有错，希望大家指出。我的SDWebImage版本是（4.4.1） pod 'SDWebImage', '~> 4.4.1' （应该是在4.0以上的都可以）
方法是
[imageview sd_setImageWithURL:[NSURL URLWithString:url ]placeholderImage:nil options:SDWebImageRefreshCached];
我之前的写法是：
[imageview sd_setImageWithURL:[NSURL URLWithString:url ]placeholderImage:nil ];
区别在于多加啦一个参数：options：SDWebImageRefreshCached
SDWebImageRefreshCached参数设置之后，会怎么样？
不使用SDWebImage提供的内存缓存和硬盘缓存
采用NSURLCache提供的缓存，有效时间只有5秒
图片不一致的问题是解决了，不过效果跟不使用缓存差别不大
个人建议这个参数还是不要用为好，为了一个小特性，丢掉了SDWebImage最核心的特色。
解决方案
方案1
后台给的url中增加字段，表示图片是否更新，比如增加一个timestamp字段.图片更新了，就更新下这个字段；
对客户端来说，只要这个timestamp字段变了，整个url就不一样了，就会从网络取图片。比如http://xxx/xx? timestamp=xxx
也可以添加图片文件的md5来表示文件是否更新，比如http://xxx/xx? md5=xxx。并且md5比时间戳要好，这是强校验。时间戳在服务器回滚或者服务器重启的时候会有特殊的逻辑。不过大多数时候时间戳也够用了。
====这个方案客户端不用改，后台改动也不会太大。====强烈推荐
方案2
客户端修改缓存策略，只用内存缓存，不用磁盘缓存。就是设置SDWebImageCacheMemoryOnly参数。
这个方案的好处是服务端不用改，客户端改动很少。
但是问题是程序关闭又打开之后，缓存就没了，需要访问网络，重新加载图片，缓存性能下降很多
方案3
客户端修改缓存时间。目前的缓存有效时间为7天，有点长；可以修改为一个经验值，比如1天？1小时？
这个方案的好处是服务端不用改，客户端也改动很少，缓存性能下降程度比方案二要小一点；
缺点是：在缓存时间内，不一致的问题还是存在的，问题只是减轻，并没有消除
方案4
客户端不用现在的第三方库（SDWebImage），（设置SDWebImageCacheMemoryOnly参数方案不推荐），采用系统API实现（NSURLCache）。服务端利用Http的头部字段进行缓存控制。
Cache-Control：可以设定缓存有效时间，默认是5s，具体时间由服务端设置。设置一个经验值，1天？1小时？
Last-Modified/If-Modified-Since：时间戳。有更新服务端就返回200，客户端下载，更新图片；没更新，服务端就返回304，客户端使用本地缓存。
Etag/If-None-Match：标签，一般用MD5值。有更新服务端就返回200，客户端下载，更新图片；没更新，服务端就返回304，客户端使用本地缓存。
这个方案的优点是：服务端控制缓存，并且既有全局控制（缓存有效时间），又有特定的控制（时间戳或者MD5标签）
缺点：客户端不能利用成熟的第三方库，需要自己实现图片缓存，非主流用法。服务端改动也非常大。====不推荐
备注：
选方案1的应该普遍一点，比较简单；
选方案4也是可以的，不过要求服务端客户端配合开发，并且也没有必要用SDWebImage，直接用系统API来做就是了
总结：这是一道经常问的面试题，希望对你有帮助。谢谢你的阅读，如有不妥的请指出！
