AWS S3中Content-Encoding:gzip是仅传输压缩还是持久存储压缩？

单纯给S3存储的对象配置'Content-Encoding': 'gzip'元数据，完全不会减小S3中存储文件的实际体积。

S3是典型的对象存储服务，核心逻辑是原样存储用户上传的字节流、原样返回用户配置的对象元数据，不会根据Content-Encoding这类HTTP头自动做压缩、解压操作：

• 如果你上传的是未压缩的原始GIF文件，哪怕手动给对象加上Content-Encoding: gzip元数据，S3存的还是完整的未压缩文件，存储体积没有任何变化。反而用户访问时，客户端会根据这个头尝试用gzip规则解析返回内容，直接导致文件解析失败、图片无法加载。
• 只有你在本地提前把文件用gzip算法压缩完成，上传压缩后的字节流，同时给对象配置正确的Content-Encoding: gzip元数据，S3才会存储这个压缩后的版本，实际存储体积才会对应减小。对外提供服务时S3会原样返回压缩内容和对应头，支持gzip解码的客户端会自动解压拿到原始GIF正常展示，不支持gzip的客户端则会直接拿到压缩后的文件。

补充说明：Content-Encoding头的作用只是告知接收方当前返回内容的编码格式，提示客户端用对应规则解码得到原始资源，它本身不触发任何存储侧的自动处理逻辑。

注意GIF本身已经是经过压缩的图片格式，gzip对GIF的压缩率非常有限，通常仅能缩减5%~10%的体积，绝大多数场景下没法靠gzip把超大小的GIF压到阈值以内，推荐按优先级选方案：

• 优先在上传前做GIF本体优化：通过压缩工具降低帧率、缩减分辨率、减少调色板颜色数、使用有损压缩参数（可使用gifsicle、ffmpeg等工具处理），这是体积缩减效果最明显的方案，不会带来额外的兼容性问题
• 如果确实要使用gzip压缩存储：必须先在本地完成文件的gzip压缩，再上传压缩后的文件，同时正确配置Content-Encoding: gzip元数据，绝对不要给未压缩的文件设置这个头，否则会导致资源加载异常
• 如果搭配CloudFront做分发，不要对GIF这类已压缩格式开启动态压缩功能，避免出现头信息错乱、内容解析失败的问题

内容的提问来源于stack exchange，提问作者user19473296