Java 用 GZIPOutputStream 压缩 XML 流应直接操作内存数据，需指定 UTF- 8 编码、用 OutputStreamWriter 包装、调用 finish() 和 close()，并正确设置 Content-Encoding: gzip 与 Content-Type: application/xml。
Java 用 GZIPOutputStream 压缩 XML 流，别先写文件
直接压缩内存中的 XML 数据流（比如 String 或 Document）再发 HTTP，比先生成临时 XML 文件再 gzip 更快、更省内存。核心是把 XML 内容塞进 GZIPOutputStream 包裹的 ByteArrayOutputStream，而不是操作磁盘文件。
常见错误现象：IOException: Stream closed 或压缩后解压乱码——多半是没设好字符编码，或提前 close() 了底层流。
- XML 原始内容必须明确指定编码（推荐
UTF-8），写入前用new OutputStreamWriter(gzipStream, StandardCharsets.UTF_8) - 不要用
String.getBytes()直接喂给GZIPOutputStream，会丢编码信息；必须经Writer层转换 - 调用
gzipStream.finish()再gzipStream.close()，否则尾部校验字节可能缺失，导致解压失败
HTTP 传输时必须设对两个 header：Content-Encoding 和 Content-Type
服务端压缩了，客户端才能正确解压。光压不告诉对方“我压了”，等于白干。
使用场景：Spring RestTemplate 发 POST、OkHttp 手动构造请求、Servlet 响应流输出等。
立即学习 “Java 免费学习笔记（深入）”；
-
Content-Encoding: gzip必须显式设置，不能依赖客户端猜 -
Content-Type仍为application/xml或text/xml，不要改成application/gzip——那是压缩包类型，不是压缩流 - 如果用
HttpClient发送，记得禁用自动 gzip 解压（setContentEncoding(null)），否则它会在你不知情时偷偷解压，后续逻辑收不到压缩体
Transformer 输出到 GZIPOutputStream 的坑：不能跳过 OutputKeys.ENCODING
如果你用 Transformer（比如从 Document 生成 XML 字符串），直接输出到 gzip 流时，不设编码会导致 XML 声明里的 encoding 属性和实际字节不一致，某些严格解析器会报错。
参数差异：transformer.setOutputProperty(OutputKeys.ENCODING, "UTF-8") 不只是格式美化，它决定了 Writer 实际用什么编码写入。
- 漏设
ENCODING→ XML 声明写encoding="UTF-8"，但实际按平台默认编码（如 Windows-1252）写入 → 解压后解析失败 - 设了
ENCODING但没配对应的OutputStreamWriter→ 属性对了，Writer 还是用错编码 → 同样乱码 - 示例关键片段：
transformer.setOutputProperty(OutputKeys.ENCODING, "UTF-8"); transformer.transform(source, new StreamResult(new OutputStreamWriter(gzipOut, StandardCharsets.UTF_8)));
接收端解压失败？先检查 GZIPInputStream 是否能读满整个流
网络传输中，TCP 分包可能导致 GZIPInputStream 在第一次 read() 就返回 -1，误判为流结束，实际数据还没来全。
性能影响：用 BufferedInputStream 包一层再喂给 GZIPInputStream，能显著减少小包读取次数，避免频繁阻塞。
- 不要直接 new
GZIPInputStream(socket.getInputStream())，加缓冲：new GZIPInputStream(new BufferedInputStream(in, 8192)) - 读取时别只调一次
read(byte[])，要用循环直到返回 -1，且确保available()不代表真实可读字节数（它在压缩流里基本没用） - 如果用 Spring WebMvc 接收，确保客户端发的是标准 gzip 流，不是 zip 包或 base64 编码过的二进制——这类非标准封装得自己拆，框架不认
XML 流压缩本身不难，但编码、流生命周期、HTTP 协议头这三处一旦错一个，就卡在“明明压了却解不开”上。特别是 Transformer 的 encoding 属性和 OutputStreamWriter 的 charset 必须严格一致，这点容易被忽略。
