Java 中可通过 ZipOutputStream 设置 Deflater.NO_COMPRESSION 实现零压缩 ZIP 打包，显著提升大文件批量归档速度；关键在于正确设置压缩级别、确保 ZIP 条目写入完整性，并避免手动调用 flush() 干扰内部状态。
java 中可通过 `zipoutputstream` 设置 `deflater.no_compression` 实现零压缩 zip 打包，显著提升大文件批量归档速度；关键在于正确设置压缩级别、确保 zip 条目写入完整性，并避免手动调用 `flush()` 干扰内部状态。
在高性能文件归档场景中（如 Web 接口批量下载），压缩往往成为性能瓶颈。Java 原生 java.util.zip 支持无压缩存储模式（STORED），即仅将原始字节按 ZIP 格式封装，不执行任何压缩算法——这正是 Deflater.NO_COMPRESSION 所启用的模式。但实践中常见“ZIP 文件损坏”问题（如 Windows 解压报错 “ERROR 1: process doesn't exist” 或 macOS 提示 “archive is damaged”），根源通常并非 API 不可用，而是使用方式不合规。
✅ 正确做法：三步到位
必须在 putNextEntry() 之前设置压缩级别
setLevel() 仅对后续写入的条目生效，且需在每个 ZipEntry 创建前调用（或全局设一次，但须确保无前置 entry）。错误地在 putNextEntry() 后设置，或在流已开始写入数据后调用，会导致 ZIP 结构异常。为每个 ZipEntry 显式指定 setMethod(ZipEntry.STORED)
单靠 setLevel(Deflater.NO_COMPRESSION) 不足以保证 STORED 模式——JDK 默认仍可能使用 DEFLATED 方法并传入 0 级压缩，而某些解压工具（尤其是 Windows 内置解压器）对此兼容性差。必须显式调用 zipEntry.setMethod(ZipEntry.STORED)，并计算并设置 crc、size、compressedSize，否则 ZIP 标准校验失败。禁用手动 flush()，依赖 closeEntry() 自动完成
手动 zipOutputStream.flush() 可能截断 ZIP 条目尾部元数据（如 CRC 校验块），导致 ZIP 结构不完整。应完全交由 closeEntry() 自动写入必要字段。
✅ 完整可运行示例（Servlet 场景）
response.setContentType("application/zip");
response.setHeader(HttpHeaders.CONTENT_DISPOSITION,
ContentDisposition.attachment()
.filename("download.zip", StandardCharsets.UTF_8)
.build()
.toString());
// 注意：若无法预知 totalSize，建议移除 setContentLengthLong 或改用 chunked transfer
try (ZipOutputStream zipOut = new ZipOutputStream(response.getOutputStream())) {
// 全局设置（可选，但非充分条件）
zipOut.setLevel(Deflater.NO_COMPRESSION);
for (FileSystemResource file : resources) {
String filename = file.getFilename().toString();
try (InputStream in = file.getInputStream()) {
// ✅ 关键：创建 entry 并强制 STORED 模式
ZipEntry entry = new ZipEntry(filename);
entry.setMethod(ZipEntry.STORED); // 强制无压缩存储
// ✅ 必须提供 CRC 和尺寸（STORED 模式下不可省略）
byte[] bytes = StreamUtils.copyToByteArray(in);
entry.setSize(bytes.length);
entry.setCompressedSize(bytes.length);
entry.setCrc(calculateCrc32(bytes));
zipOut.putNextEntry(entry);
zipOut.write(bytes); // 直接写入字节数组
zipOut.closeEntry(); // ✅ 自动完成 CRC/size 写入，禁止 flush()
}
}
}
辅助方法（计算 CRC32）：
private static long calculateCrc32(byte[] data) {
CRC32 crc = new CRC32();
crc.update(data);
return crc.getValue();
}
⚠️ 注意事项与避坑指南
- 不要混合使用 setLevel() 和 setMethod() 的模糊调用：setLevel(0) ≠ setMethod(STORED)。前者是 Deflate 算法的 0 级（仍属 DEFLATED 方法），后者才是 ZIP 规范定义的无压缩存储类型。
- setContentLengthLong(totalSize) 需谨慎：若 totalSize 计算未包含 ZIP 元数据开销（每个 entry 约 30+ 字节头 + central directory），可能导致客户端接收不完整流。建议在流式场景中省略该头，或使用 Transfer-Encoding: chunked。
- 大文件内存考量：上述示例使用 copyToByteArray() 适合中小文件；若处理 GB 级文件，应改用带缓冲的流式读写，并预先计算 CRC 和 size（可通过 Files.size() + CRC32 分块计算实现）。
- 兼容性验证：生成 ZIP 后，务必用 unzip -t download.zip（Linux/macOS）或 7-Zip（Windows）校验，而非仅依赖系统自带解压器。
通过以上规范实现，即可获得标准、高速、跨平台兼容的无压缩 ZIP 归档，兼顾性能与可靠性。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
