在接口通信中，数据传输量过大会导致：响应时间变长、带宽占用过高、移动端流量消耗增加。数据压缩技术通过对请求 / 响应数据进行压缩编码（如 Gzip、Deflate），能显著减小数据体积（通常压缩率可达 50%-80%），实现 “轻量交互”，是提升接口性能的 “低成本高回报” 方案。
数据压缩的适用场景与原理
哪些数据适合压缩？
-
文本类数据：JSON、XML、HTML 等（压缩率高，如 100KB 的 JSON 可压缩至 20KB）
-
大体积响应：如列表查询（100 条以上数据）、报表数据
-
低频更新数据：如商品详情、静态配置（可结合缓存进一步优化）
不适合压缩的场景：
- 已压缩的数据：图片（JPG/PNG）、视频（MP4）等二进制文件（再次压缩效果差，还会增加 CPU 开销）
- 极小数据：如仅返回
{"code":200}（压缩后可能比原数据还大，因需添加压缩头）
压缩的工作流程
- 客户端在请求头中声明支持的压缩算法（如
Accept-Encoding: gzip, deflate） - 服务器根据声明的算法对响应数据进行压缩
- 服务器在响应头中说明使用的压缩算法（如
Content-Encoding: gzip） - 客户端收到数据后，按响应头的算法解压并处理
后端实现数据压缩的两种方式
1. 全局压缩配置：自动压缩符合条件的响应
Spring Boot 可通过配置开启全局 Gzip 压缩，自动处理响应数据：
# application.yml 配置
server:
compression:
enabled: true # 开启压缩
mime-types: application/json, application/xml, text/html, text/plain # 需要压缩的MIME类型
min-response-size: 1024 # 最小压缩阈值（字节），小于此值不压缩
compression-level: 6 # 压缩级别（1-9），级别越高压缩率越高，但CPU消耗越大
压缩级别选择：
- 开发 / 测试环境：可用较高级别（如 6-7），平衡压缩率和 CPU 开销
- 生产环境（高并发）：建议用中低级别（如 3-5），避免压缩占用过多 CPU 资源
2. 手动压缩：针对特定接口的精细化控制
对于全局配置无法满足的场景（如仅对某接口压缩、使用自定义压缩算法），可手动实现压缩：
@GetMapping("/large-data")
public void getLargeData(HttpServletRequest request, HttpServletResponse response) throws IOException {
// 1. 生成大体积数据（如1000条商品列表）
List<Product> products = productService.getLargeList();
String jsonData = JSON.toJSONString(products);
byte[] data = jsonData.getBytes(StandardCharsets.UTF_8);
// 2. 检查客户端支持的压缩算法
String acceptEncoding = request.getHeader("Accept-Encoding");
if (acceptEncoding != null && acceptEncoding.contains("gzip")) {
// 3. 使用Gzip压缩
response.setHeader("Content-Encoding", "gzip");
try (GZIPOutputStream gzipOut = new GZIPOutputStream(response.getOutputStream())) {
gzipOut.write(data);
}
} else {
// 不压缩，直接返回
response.getOutputStream().write(data);
}
}
手动压缩的优势：
- 可根据业务场景动态决定是否压缩（如 VIP 用户不压缩以减少等待时间）
- 可自定义压缩逻辑（如对敏感字段加密后再压缩）
压缩优化的进阶技巧
1. 结合缓存：减少重复压缩开销
压缩操作会消耗 CPU，对高频访问的接口，可缓存压缩后的结果：
@Service
public class CompressedDataService {
@Autowired
private RedisTemplate<String, byte[]> redisTemplate;
// 获取压缩后的缓存数据
public byte[] getCompressedData(String key, Supplier<byte[]> dataSupplier) {
// 尝试从缓存获取压缩后的数据
byte[] compressedData = redisTemplate.opsForValue().get("compressed:" + key);
if (compressedData != null) {
return compressedData;
}
// 缓存未命中，生成数据并压缩
byte[] rawData = dataSupplier.get();
compressedData = gzipCompress(rawData);
// 存入缓存（设置10分钟过期）
redisTemplate.opsForValue().set("compressed:" + key, compressedData, 10, TimeUnit.MINUTES);
return compressedData;
}
// Gzip压缩工具方法
private byte[] gzipCompress(byte[] data) {
try (ByteArrayOutputStream out = new ByteArrayOutputStream();
GZIPOutputStream gzipOut = new GZIPOutputStream(out)) {
gzipOut.write(data);
gzipOut.finish();
return out.toByteArray();
} catch (IOException e) {
throw new RuntimeException("压缩失败", e);
}
}
}
2. 前端配合：请求压缩减少上传流量
除了响应压缩，还可对大体积请求（如批量提交表单）进行压缩，前端压缩后发送，后端解压：
// 处理压缩的请求体
@PostMapping("/batch-save")
public Result batchSave(@RequestBody byte[] compressedData, HttpServletRequest request) throws IOException {
// 检查请求是否压缩
String contentEncoding = request.getHeader("Content-Encoding");
byte[] rawData = compressedData;
if (contentEncoding != null && contentEncoding.contains("gzip")) {
// 解压
try (GZIPInputStream gzipIn = new GZIPInputStream(new ByteArrayInputStream(compressedData))) {
rawData = IOUtils.toByteArray(gzipIn);
}
}
// 解析解压后的数据
List<Item> items = JSON.parseArray(new String(rawData), Item.class);
itemService.batchSave(items);
return Result.success();
}
避坑指南
-
压缩不是 “万能药”：小数据压缩可能适得其反（压缩后的体积 + 压缩耗时 > 原数据传输耗时）
-
监控压缩效果：统计压缩率（压缩后体积 / 原体积）和压缩耗时，避免盲目开启
-
注意兼容性：部分老旧客户端可能不支持 Gzip 解压，需做好降级处理
-
避免重复压缩：若使用 CDN，需确保 CDN 和后端的压缩配置不冲突（如 CDN 已压缩，后端无需再压缩）
数据压缩是接口性能优化的 “隐形杠杆”—— 只需少量配置或代码改动，就能显著提升传输效率。它的核心是 “用 CPU 时间换带宽资源”，在带宽有限或数据量大的场景下，这种交换往往能带来明显的用户体验提升，这是后端性能优化中 “性价比” 极高的选择。
