现在市面上有很多云服务商提供对象存储服务，例如阿里云的OSS，腾讯云的COS，亚马逊的S3（PS:个人感觉腾讯阿里都是抄亚马逊的）。
以阿里云为例，OSS上的文件如果要给用户去访问，一定是通过CDN域名去访问的，不可能是直接走源站地址，走源站地址有三个坏处，一是用户可能处在天南海北，都去访问源站bucket在地理上的延迟是无法忽略的，二是访问源站的流量费比访问CDN的流量费要贵，三是走CDN可以加一些权限验证，虽然bucket也可以校验权限，但是针对bucket的校验是全局的，但是如果只开启CDN鉴权，用户访问都是通过CDN，对用户来说bucket实际是隐藏的，便于同一个模块不同的功能共用同一个bucket进行存储。
当然，通过CDN访问有一个坏处，如果你上传了一个文件，过了两天突然更新了这个文件，你在OSS上重新上传，文件名和第一次传的文件相同，用户通过CDN访问这个路径下的文件是拿不到你最新上传文件的，因为CDN的缓存机制，发现用户访问的这个文件这里正好缓存的有，就不会再去源站拉取文件，所以你上传的文件在用户那里并没有得到更新。这个时候有两种方案：1.找运维刷新CDN缓存 2.换个文件名，让用户使用新的路径去访问这个文件。但是这两种方案无论哪一种都不是很理想，如果频繁修改的文件不太可能每次都找运维强制刷新CDN缓存，如果是都是静态资源，每次更新都要带着前端一起更新去换文件路径，这两个方案无论哪个运维或前端都不太可能接受，嘴上不说但心里可能已经mmp了。
如果你在上传文件的时候利用了阿里云 OSS的header控制机制，在上传这些文件至OSS源站时，给文件设置了Cache-Control的头部，来实现的由开发或运营控制的缓存配置，就能避免被运维或前端吐槽。阿里云PutObject
Cache-Control的参数
max-age=[单位：秒 seconds] — 设置缓存最大的有效时间. 类似于 Expires, 但是这个参数定义的是时间大小（比如：60）而不是确定的时间点.单位是[秒 seconds].
s-maxage=[单位：秒 seconds] — 类似于 max-age, 但是它只用于公享缓存 (e.g., proxy) .
public — 响应会被缓存，并且在多用户间共享。正常情况, 如果要求 HTTP 认证,响应会自动设置为 private.
private — 响应只能够作为私有的缓存(e.g., 在一个浏览器中)，不能再用户间共享.
no-cache — 响应不会被缓存,而是实时向服务器端请求资源。这一点很有用，这对保证HTTP 认证能够严格地禁止缓存以保证安全性很有用（这是指页面与public结合使用的情况下）.既没有牺牲缓存的效率，又能保证安全.
no-store — 在任何条件下，响应都不会被缓存，并且不会被写入到客户端的磁盘里，这也是基于安全考虑的某些敏感的响应才会使用这个.
must-revalidate — 响应在特定条件下会被重用，以满足接下来的请求，但是它必须到服务器端去验证它是不是仍然是最新的.
proxy-revalidate — 类似于 must-revalidate,但不适用于代理缓存.
对于经常变动的资源，我们可以设置 Cache-Control: no-cache
对于偶尔更新的资源，我们可以设置 Cache-Control:public,max-age=300,s-maxage=600
OSS源站设置好Cache-Control头部后，在CDN上，就无需做任何配置了，此时CDN会遵循 rfc2616, 依据源站的Cache-Control进行缓存设置,从而使得运维无需进行额外配置，一切由最了解资源缓存策略的开发人员进行控制，也减少了沟通成本，降低了缓存配置出错的风险。
有了上面的配置，每次更新资源后，最多等10分钟用户就能访问到最新的资源，当然，max-ag和s-maxage的参数还要根据不同业务不同配置，不能一概而论。
指定该文件被下载时网页的缓存行为，详情请参见 RFC2616
点击上面的链接打开网页，全局搜 14.9.3 Modifications of the Basic Expiration Mechanism 就可以定位到Cache-Control部分。