您的屏幕截图似乎来自Postman，显示的是解压缩后的大小，而不是压缩后的大小。
这是Postman的屏幕截图，显示了我的支持Gzip的REST服务

1. Content-Encoding正在告诉客户端它传输的内容是gzip压缩的。如果你只是设置这个头而没有压缩响应内容，这可能是不正确的。但是，因为你依赖Spring来做这件事，它很可能是正确的，并且响应是压缩的。
2. Transfer-Encoding只是表示响应可以分成多个HTTP包发送，这是在服务器事先不知道响应内容大小的情况下进行的。服务器可以通过两种方式知道响应内容的大小。第一种是将序列化的响应缓冲到内存中，然后获取其字节数组长度。第二种是在计算大小时丢弃序列化的内容。在第二个场景中，服务器将不得不序列化响应两次，一次用于查找大小，另一次用于写入ServletOutputStream。正如您所看到的，这两种提前查找响应大小的方法都是不可取的。服务器将把此Transfer-Encoding设置为块，即使您响应不是Gzip也是如此这是因为**中JSON序列化Spring的处理方式是，只要缓冲区中有JSON的任何部分可用，就允许将响应写入ServletOutputStream。这样，服务器可以更快地提供第一个字节。**即使是最小的响应也会发生这种情况。有Transfer-Encoding: chunked并不意味着您的响应没有被压缩。它意味着Gzip字节一旦可用就被写入ServletOutputStream
3. Postman只显示解压缩后的大小。你可以在Google Chrome中分别看到实际传输的大小和解压缩后的大小。

或者，您可以使用CURL命令查看这两种大小

以下是文本形式的命令

#Find uncompressed size
curl -so target/test.json localhost:8080/order -w "%{size_download}"

#Find compressed size
curl --compressed -so target/test.json localhost:8080/order -w "%{size_download}"