这个头在声明什么
Content-Encoding 声明表示层被施加了什么编码（gzip、br、deflate、identity），接收方必须按它解码才能拿到原始内容。它是表示的属性，属于端到端：链路上每一跳看到的都是同一段已编码字节（RFC 9110 §8.4）。
与传输编码的分工
容易混淆的一点是：Content-Encoding 改的是内容本身，端到端传递；Transfer-Encoding 改的是这一跳怎么把字节搬过去，逐跳生效、每跳自行处理。因此源站与 CDN 之间的编码声明必须一致，而传输编码由每一段连接各自决定。
基本信息
| 名称 | Content-Encoding |
|---|---|
| 作用 | 声明表示层编码；接收方需解码 |
| 规范 | RFC 9110 §8.4 |
| 常见取值 | gzip、br、deflate、identity |
| 对比 | Transfer-Encoding 是逐跳属性，两者不可混为一谈 |
典型使用场景
- 文本资源压缩：HTML、CSS、JS、JSON 压一遍通常能省下大半流量
- CDN 开启 Brotli 后压缩策略改变，源站与边缘的声明必须同步
- 排查乱码或字节错位：先确认声明值与真实编码是否吻合
- 抓包分析压缩比与首字节时间：判断瓶颈在压缩还是后端
查看与验证
查看与验证
# 请求时声明可接受的编码，再看响应实际用了哪种
curl -sI -H 'Accept-Encoding: gzip, br' https://www.example.com/ | grep -i content-encoding
# 组合编码按列出顺序施加，解码须逆序：Content-Encoding: gzip, br
curl -s --compressed -o /dev/null -w '%{size_download}\n' https://www.example.com/ # 自动解码后的大小取值说明
| 取值 | 说明 | 注意点 |
|---|---|---|
| gzip | 兼容性最好的通用压缩 | 对已压缩内容无效，别对图片重复压 |
| br | Brotli，同体积下压缩率通常更好 | 浏览器仅在 HTTPS 下接受，动态压缩较耗 CPU |
| deflate | 历史遗留取值 | 实现间存在原始 deflate 与 zlib 包装的分歧，易出兼容问题 |
| identity | 明确表示未编码 | 出现它通常说明压缩被显式关掉了 |
CDN 改写压缩策略后，源站返回的 Content-Encoding 必须同步改写：声明与实际编码不匹配，客户端按错误算法解码，拿到的就是乱码。
压什么也挑对象：文本类收益显著；图片、音视频、压缩包本身已压缩，再压只耗 CPU，个别情况下体积还会略微变大。