Java中GZIPOutputStream是JDK自带的gzip压缩方案，需调用close()确保CRC和长度信息写入，避免解压异常；小数据解压时read()返回0属正常，应循环至-1；多文件需先tar再gzip。
Java里gzip压缩用java.util.zip.GZIPOutputStream最直接
不用额外依赖，JDK自带，适合简单场景。它包装一个OutputStream，写入时自动压缩，底层调用zlib。
常见错误是忘记close()——不关流会导致尾部CRC和长度信息缺失，解压时抛java.util.zip.ZipException: invalid stored block lengths或类似IO异常。
- 必须调用
close()（或用try-with-resources），不能只flush() - 压缩级别用
Deflater控制：new GZIPOutputStream(out, true)第二个参数启用默认压缩，但无法自定义级别；如需设级别，得手动构造Deflater并传给GZIPOutputStream(OutputStream, Deflater) - 对小数据（
Apache Commons Compress更适合多格式统一处理
如果项目里还要处理.tar、.zip、.xz等，commons-compress比零散用JDK类更可控。它把gzip封装成ZipArchiveOutputStream的兄弟类GzipCompressorOutputStream，API更一致。
注意它不替代JDK的GZIPOutputStream，而是提供另一套实现，压缩结果完全兼容标准gzip（RFC 1952），但内部缓冲策略不同，小文件吞吐略低，大文件稳定性更好。
立即学习“Java免费学习笔记（深入）”；
将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。
- 添加Maven依赖：
<dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-compress</artifactId> <version>1.24.0</version> </dependency>
- 用法示例：
GzipCompressorOutputStream gzos = new GzipCompressorOutputStream(new FileOutputStream("out.gz")); gzos.write("hello".getBytes(StandardCharsets.UTF_8)); gzos.close(); // 同样必须close - 它支持
setBufferSize(int)，对高吞吐场景（如日志压缩）可设为64KB以上
Spring Framework的GzipResponseWrapper仅限Web响应压缩
Spring MVC没提供通用gzip工具类，但org.springframework.web.servlet.resource.GzipResponseWrapper专用于HTTP响应体压缩。它不是独立工具，而是配合ResourceHttpRequestHandler或过滤器使用的包装器。
别误以为它能压缩任意字节数组——它只在Servlet容器响应写出前拦截getOutputStream()或getWriter()，内部仍委托给GZIPOutputStream。配置不当会导致Content-Encoding未设、浏览器不解压，或乱码（没设Content-Type字符集）。
- 启用方式：在
WebMvcConfigurer中配ResourceHandlerRegistry，或加@Bean注册GzipEncodingFilter - 关键点：
response.setHeader("Content-Encoding", "gzip")必须由它自动完成，手动设容易漏掉Vary头 - 它不处理请求体解压，POST的gzip body要靠
ContentLengthFilter或自己用GZIPInputStream解析
解压时GZIPInputStream遇到EOF异常多数是流没关或数据截断
读取gzip流时抛java.io.EOFException: Unexpected end of ZLIB input stream，基本可断定输入源不完整：要么原始gzip文件被截断，要么网络传输中途断开，要么写入方没close()导致尾部校验字节丢失。
不要用available() > 0判断是否还有数据——它在gzip流里返回0是常态，正确做法是循环read(byte[])直到返回-1。
- 安全解压模板：
try (GZIPInputStream gzin = new GZIPInputStream(new FileInputStream("in.gz"))) { byte[] buf = new byte[8192]; int len; while ((len = gzin.read(buf)) != -1) { // 处理buf[0..len) } } - 若输入来自HTTP响应，确认服务端确实返回了
Content-Encoding: gzip且响应体完整（检查Content-Length或用chunked编码） - Android上部分旧版本API对gzip尾部校验更敏感，建议用
Okio.source().gzip()替代原生类
commons-compress的TarArchiveOutputStream + GzipCompressorOutputStream组合。 
