Spring Boot实现REST接口Gzip压缩需启用响应压缩、精准控制范围并规避失效陷阱：配置server.compression.enabled=true等参数，显式声明mime-types，修复POJO返回不压缩问题（强制设置Content-Length），排除二进制类型，并验证Accept-Encoding与Content-Encoding头。
Spring Boot 实现 REST 接口的高性能 Gzip 压缩传输，核心是启用响应压缩、精准控制压缩范围，并规避常见失效陷阱。默认不开启，需主动配置；不是所有 JSON 响应都会被压缩，关键取决于响应头、内容长度和 MIME 类型匹配。
基础配置：启用并限定压缩范围
在 application.yml 中添加以下配置即可快速启用：
- server.compression.enabled=true：全局开启 HTTP 响应压缩
- server.compression.min-response-size=1024：仅压缩 ≥1KB 的响应（避免小响应徒增 CPU 开销）
-
server.compression.mime-types：显式声明需压缩的类型，推荐包含：
application/json,application/xml,text/html,text/plain,text/css,application/javascript
注意：Spring Boot 2.0+ 默认已内置常见文本 MIME 类型，但显式列出更可控，尤其当项目返回 application/geo+json 或自定义 JSON 子类型时，必须手动加入。
关键修复：解决 Controller 返回对象不压缩的问题
很多场景下，@RestController 返回 POJO（如 Result<List<User>>），即使响应体远超 2KB，Gzip 仍不生效——根本原因是 Spring MVC 默认不设置 Content-Length，而是用 Transfer-Encoding: chunked 流式发送，导致压缩器无法判断是否达到 min-response-size 阈值。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
解决方法：强制写入 Content-Length 头。推荐使用 ResponseEntity 显式构造响应：
- 将返回值从
MyData改为ResponseEntity<MyData> - 在 Controller 中调用
ResponseEntity.ok().contentLength(byteLength).body(data) - 或配合
@ControllerAdvice全局拦截ResponseBody，用HttpServletResponse.setContentLength()补全长度
进阶优化：按需启用，避开压缩反效果场景
Gzip 对已压缩资源（如 JPEG、PNG、ZIP 文件）无效甚至可能略增体积，因此务必排除：
- 不要在
mime-types中包含image/*、application/pdf、application/zip等二进制类型 - 若接口明确返回文件流（
Resource或InputStreamResource），建议禁用压缩：通过@RequestMapping(produces = "image/png")绕过压缩逻辑，或用 Filter 动态跳过特定路径 - 高并发低延迟场景可设
min-response-size=4096，进一步降低 CPU 占用，牺牲少量小响应的压缩收益
验证与调试技巧
压缩是否生效不能只看响应大小，要确认三点：
- 请求头含
Accept-Encoding: gzip（现代浏览器默认携带） - 响应头含
Content-Encoding: gzip且Content-Length明显变小（通常压缩率 70%~90%） - 响应体原始内容可被
gunzip -t或在线工具解压校验 - 用 curl 测试：
curl -H "Accept-Encoding: gzip" -I http://localhost:8080/api/data，检查返回头
