ZipOutputStream解压后为空目录的根本原因是未调用closeEntry()；目录条目也需调用，且不能依赖close()自动补全。
ZipOutputStream写入文件时为什么解压后是空目录？
根本原因是没调用 closeEntry() —— 很多人只写了 putNextEntry() 就直接写数据，忘了收尾。ZIP格式要求每个条目必须显式关闭，否则解压工具认为该条目没结束，跳过或当成损坏处理。
常见错误现象：unzip 命令报 invalid compressed data to inflate，或者 Windows 解压后看到一堆空文件夹。
- 必须在写完一个文件内容后立即调用
zos.closeEntry() - 如果写的是目录（路径以
/结尾），putNextEntry()后不能写任何字节，但依然要调用closeEntry() - 别依赖
zos.close()自动补全——它不会帮你关未完成的条目
zos.putNextEntry(new ZipEntry("src/"));
// 目录不写内容，但必须 close
zos.closeEntry(); // ← 这行不能省
ZipInputStream读取时 getInputStream() 返回 null 怎么办？
不是流坏了，是当前 ZipEntry 本身不带数据——比如它是目录、或压缩方式为 STORED 但实际长度为 0。Java 的 ZipInputStream 对这类条目会返回 null，而不是抛异常。
使用场景：遍历 ZIP 内容做条件提取（比如只解压 .log 文件），容易在这里卡住。
立即学习“Java免费学习笔记（深入）”；
- 先检查
ze.getSize() != 0或ze.isDirectory() == false - 再判断
ze.getMethod() == ZipEntry.STORED且ze.getCrc() == 0，可能也是空条目 - 永远用
if (in != null)包一层再读，别直接in.read(...)
ZipEntry ze = zis.getNextEntry();
if (ze != null && !ze.isDirectory() && ze.getSize() > 0) {
InputStream in = zis.getInputStream(); // 此时才安全
}
中文文件名乱码（Windows 上最常见）
标准 ZIP 规范不强制指定编码，默认按系统 locale 解释文件名。JDK 原生 ZipInputStream/ZipOutputStream 只支持 UTF-8（从 Java 7 开始可配，但默认关着），而 Windows 默认用 GBK 打包的 ZIP，一读就变问号。
兼容性影响：用 java.util.zip 读老 ZIP 几乎必乱码；用 org.apache.commons.compress 可控，但得手动设编码。
- 写 ZIP 时，强制用 UTF-8：设置系统属性
-Dsun.zip.encoding=UTF-8（仅 Java 7+ 有效） - 更稳的做法：改用
org.apache.commons.compress.archivers.zip.ZipArchiveOutputStream，调用setEncoding("UTF-8") - 读 ZIP 时，如果已知是 GBK 打包的，只能用
ZipArchiveInputStream并指定setEncoding("GBK")
大文件压缩内存爆掉或卡死
ZipOutputStream 本身不缓存整个文件，但如果你把大文件一次性读进 byte[] 再写，就等于双倍内存占用。另外，没设缓冲区大小会导致频繁小块 IO，慢到像卡住。
性能影响：100MB 文件用 1KB 缓冲区，IO 次数多 10 万倍；用 8KB 是合理起点。
- 永远用
byte[] buffer = new byte[8192]分块读写 - 别用
Files.readAllBytes()加载大文件进内存 - 压缩级别别盲目设
Deflater.BEST_COMPRESSION，对 CPU 和时间消耗陡增，收益却很小
byte[] buf = new byte[8192];
int len;
while ((len = fis.read(buf)) != -1) {
zos.write(buf, 0, len); // 分块写，不攒整块
}
事情说清了就结束。真正难的不是 API 调用，是那些没报错却让 ZIP 在不同环境里行为分裂的细节——比如空条目、编码隐含假设、缓冲区大小和压缩级别的组合效应。 
