ZipOutputStream写入多个文件时必须显式调用putNextEntry和closeEntry，路径须用正斜杠、使用相对路径，中文名需UTF-8编码或改用Apache Commons Compress，且必须用try-with-resources确保正确关闭。
ZipOutputStream 写入多个文件时必须手动设置 putNextEntry
不调用 putNextEntry 就直接写数据，ZIP 包会损坏，解压时提示“invalid zip file”或“cannot open file”。ZipOutputStream 不像 FileOutputStream 那样自动管理文件边界——每个待压缩文件都必须显式声明一个 ZipEntry，再写入内容。
常见错误是循环中只创建 ZipEntry 但忘了调用 zos.putNextEntry(entry)，结果只有第一个文件能解出来，其余全丢。
-
ZipEntry的路径名必须用正斜杠/（即使在 Windows 上），例如"images/logo.png"，不能用"images\logo.png" - 调用
putNextEntry后必须紧接着写入该文件内容，不能穿插其他putNextEntry或跳过写入 - 每个
entry写完后要调用zos.closeEntry()，否则后续条目可能被截断
文件路径处理不当会导致 ZIP 内目录结构异常
如果传入 new ZipEntry(new File("D:/data/report.txt").getAbsolutePath())，ZIP 里会出现完整盘符路径，解压时可能生成 D:data
eport.txt 这种绝对路径，多数解压工具会拒绝或报错。
正确做法是提取相对路径：用目标根目录做基准，计算每个文件的相对路径作为 entry 名。
立即学习“Java免费学习笔记（深入）”；
- 假设要压缩
/home/user/docs/a.txt和/home/user/docs/sub/b.pdf，根目录设为/home/user/docs，则 entry 名应为"a.txt"和"sub/b.pdf" - Java 11+ 可用
Paths.get(root).relativize(Paths.get(file))安全计算；旧版本建议用file.getAbsolutePath().substring(root.length())（需确保 root 以/结尾且与 file 路径一致） - 空目录需显式添加
ZipEntry并以/结尾，例如new ZipEntry("empty-dir/")，然后调用putNextEntry+closeEntry
中文文件名乱码问题本质是编码不匹配
默认 ZipOutputStream 使用 IBM437 编码写入文件名，遇到中文就变成乱码或被截断。JDK 7+ 提供了 ZipOutputStream(OutputStream, Charset) 构造函数，但仅当底层 ZIP 工具支持 ZIP64 和 UTF-8 标志位时才真正生效——而 Windows 自带解压工具（包括资源管理器）至今不识别该标志。
- 最兼容方案：避免中文文件名，改用拼音或英文命名
- 若必须支持中文，推荐改用
Apache Commons Compress库的ZipArchiveOutputStream，它默认启用 UTF-8 并兼容 Windows 解压器 - 不要试图用
new String(filename.getBytes("GBK"), "UTF-8")临时转码——这是典型双编码陷阱，反而加剧乱码
内存与流关闭顺序直接影响 ZIP 完整性
忘记调用 zos.close() 或在写入中途抛异常未 close，ZIP 文件末尾缺少 EOCD（End of Central Directory）记录，所有解压工具都会报“truncated ZIP”。
- 必须用 try-with-resources 包裹
ZipOutputStream和底层FileOutputStream，否则流未 flush 就关闭，数据丢失 - 不要在循环内为每个文件新建
ZipOutputStream——开销大且易出错；一个 ZIP 包对应一个ZipOutputStream实例 - 大文件（>100MB）建议配合
BufferedOutputStream提升写入性能：new ZipOutputStream(new BufferedOutputStream(new FileOutputStream("out.zip")))
实际压缩逻辑里最容易被忽略的是 closeEntry 的调用时机和 Charset 构造函数的 JDK 版本限制——这两点出错，ZIP 看似生成成功，却在交付时被用户反馈打不开。
