根本原因是未调用closeEntry()和close()——ZIP格式要求末尾写入中央目录，仅write()无法封口；必须严格按putNextEntry()→write()→closeEntry()流程操作每个条目，并在最后调用zipOut.close()或使用try-with-resources确保中央目录完整写入。
ZipOutputStream 写入内存时为什么没生成压缩数据？
直接用 ZipOutputStream 写入 ByteArrayOutputStream 后调用 toByteArray() 却得到空数组或损坏 ZIP，根本原因是：ZIP 格式要求在流末尾写入中央目录结构，而 closeEntry() 和 close() 才会触发该写入。只调用 write() 不够，漏掉关闭动作就等于 ZIP 文件没封口。
- 必须对每个条目调用
putNextEntry()→write()→closeEntry() - 所有条目写完后，必须调用
zipOut.close()（或close()对应的 try-with-resources） - 如果用
try-with-resources，确保ZipOutputStream是最外层资源，否则内层流提前关闭会导致中央目录写不全
如何正确构造内存 ZIP 并避免中文文件名乱码？
ZipOutputStream 默认使用 IBM437 编码处理文件名，在中文系统下直接传入 "报告.pdf" 会变成乱码或被截断。Java 7+ 提供了 ZipOutputStream(OutputStream, Charset) 构造函数，但仅当底层 ZIP 实现支持 ZIP64 和 UTF-8 标志位时才真正生效——OpenJDK 与 Oracle JDK 8u92+、11+ 默认启用，但旧版本需手动设置。
- 优先使用
new ZipOutputStream(baos, StandardCharsets.UTF_8) - 若需兼容 JDK 7 或老旧环境，改用
org.apache.commons.compress.archivers.zip.ZipArchiveOutputStream，它默认支持 UTF-8 文件名且更稳定 - 注意：即使指定了 UTF-8，解压端也要支持 ZIP 中的 UTF-8 标志（如 Windows 资源管理器不支持，推荐 7-Zip 或 macOS 归档实用工具）
向 ZIP 添加空文件夹或带路径的文件要注意什么？
ZIP 规范中“文件夹”本质是名称以 / 结尾的 ZipEntry，且必须显式创建；否则 "data/config.json" 这样的路径不会自动建立 data/ 目录。
- 添加目录：新建
ZipEntry("data/")，调用putNextEntry()+closeEntry()，不写任何内容 - 添加带路径文件：
ZipEntry名称必须用/分隔，不能用File.separator（Windows 下是\，ZIP 不认） - 重复路径的
ZipEntry会覆盖前一个，比如先写"a/b.txt"再写"a/c.txt"没问题，但两次写"a/b.txt"会导致后者覆盖前者
内存 ZIP 大小超过 10MB 时性能明显下降怎么办？
用 ByteArrayOutputStream 累积整个 ZIP 数据，本质上是把全部压缩内容缓存在堆内存里。一旦 ZIP 达到几十 MB，不仅 GC 压力大，还可能触发 OutOfMemoryError，尤其在容器或低配服务中。
- 超 5MB 就该考虑切换为临时文件流：
Files.createTempFile(...)+FileOutputStream，用完删 - 若必须纯内存，可预估大小并初始化
ByteArrayOutputStream容量（ZIP 压缩后通常比原始小 30–70%，按 0.5 系数估算） - 不要在循环里反复调用
toByteArray()，它每次都会复制整个字节数组；写完一次后缓存结果即可
关键点始终是：closeEntry() 和 close() 不可省，UTF-8 编码不是设了就生效，路径分隔符必须用 /，而内存容量限制往往比逻辑错误更早暴露问题。
