在使用 zip4j 创建密码保护 ZIP 文件时，若在 try 块中直接返回 ByteArrayOutputStream.toByteArray()，会导致 ZIP 文件头未写入而报 “inappropriate format” 错误；关键在于 finally 块执行时机与字节数组快照生成顺序——必须确保 ZipOutputStream.close() 在获取字节数组前完成。
在使用 zip4j 创建密码保护 zip 文件时，若在 `try` 块中直接返回 `bytearrayoutputstream.tobytearray()`，会导致 zip 文件头未写入而报 “inappropriate format” 错误；关键在于 `finally` 块执行时机与字节数组快照生成顺序——必须确保 `zipoutputstream.close()` 在获取字节数组前完成。
ZIP 文件格式要求元数据（如中央目录、EOCD 记录等）必须写在文件末尾，而 ZipOutputStream 正是在调用 close() 时才将这些关键结构 flush 并写入底层输出流。当你在 try 块中执行 return out.toByteArray() 时，JVM 的执行流程是：
- 先求值：out.toByteArray() 立即拷贝当前 ByteArrayOutputStream 内部缓冲区的全部字节（此时 zipFile.close() 尚未执行，ZIP 结尾结构未写入）；
- 再执行 finally：zipFile.close() 被调用，触发 ZIP 头部/尾部写入，但这些字节已写入 out 的内部缓冲区——然而返回值早已确定，不会包含这部分新增内容；
- 最终返回的字节数组缺失 ZIP 必需的结尾结构，解压工具因此判定为“格式不恰当”。
✅ 正确做法是：确保 ZipOutputStream.close() 完成后再调用 toByteArray()。如下所示：
fun createZipFile(filename: String, vararg containers: Pair<String, ByteArray?>): ByteArray {
val out = ByteArrayOutputStream()
val zipFile = ZipOutputStream(out, passwordGenerator.generate())
for ((name, file) in containers) {
if (file != null) {
val parameters = createZipParameters(name)
zipFile.putNextEntry(parameters)
zipFile.write(file)
zipFile.closeEntry()
}
}
zipFile.close() // ✅ 关键：必须在此处关闭，触发 ZIP 尾部写入
return out.toByteArray() // ✅ 此时字节数组已包含完整 ZIP 结构
}⚠️ 注意事项：
- ByteArrayOutputStream 不需要显式 close() —— 它是内存流，无系统资源需要释放；调用 close() 不仅冗余，还可能引发 IOException（尽管通常被忽略）；
- ZipOutputStream.close() 会自动调用底层 out.close()（即 ByteArrayOutputStream.close()），但后者无实际作用，故可省略；
- 若使用静态分析工具（如 Detekt 或 SonarQube）警告“流未关闭”，请配置规则忽略 ByteArrayOutputStream，而非强行添加无意义的 out.close() —— 代码可读性与正确性优先于机械合规。
? 总结：ZIP 是“延迟写入格式”，其完整性依赖 close() 的最终 flush 行为。任何在 close() 前截取字节数组的操作都会导致损坏。牢记「先 close，再 toByteArray」这一黄金顺序，即可彻底规避 “inappropriate format” 错误。
