ZipException需精准诊断而非简单捕获：通过异常消息关键词判断真损坏（如“invalid CEN header”）或配置错误；封装为ArchiveCorruptionException保留原始异常链；日志必须输出完整堆栈；确认损坏后安全清理文件并自动重下载。

ZipException 不是“一捕获就完事”的异常，它背后往往指向真实文件问题——比如下载中断、传输损坏、格式伪装或加密未处理。关键不是吞掉异常，而是快速判断：这到底是真损坏，还是配置/编码/调用方式错了？

先确认是不是真损坏，别冤枉代码

不能光看 instanceof ZipException 就认定文件坏了。得看异常消息里的“关键词”：

• “invalid CEN header” 或 “invalid LOC header”：中央目录或本地头损坏，ZIP 结构已破坏，基本可判定文件不可用
• “zip file is empty” 或 “error in opening zip file”：文件为空、魔数（PK\x03\x04）缺失，大概率是下载不完整
• “invalid stored block lengths”：Deflate 数据块校验失败，常见于传输截断或磁盘写入异常

建议用 e.getMessage().toLowerCase().contains("invalid cen") 这类字符串匹配，比仅靠类型判断更可靠。

别丢原始堆栈，封装成业务异常再抛

直接 throw new RuntimeException("解压失败") 会切断异常链，丢失定位线索。正确做法是定义一个业务异常：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

立即学习“Java免费学习笔记（深入）”；

• 新建 ArchiveCorruptionException extends RuntimeException
• 构造函数里调用 super(message, cause)，把原始 ZipException 作为 cause 传入
• 避免手动 e.initCause()，容易遗漏

日志必须带完整异常链

只记 logger.error("解压失败: {}", e.getMessage()) 是无效的。必须写成：

logger.error("解压失败，文件路径: {}", zipPath, e);

这样 Log4j/SLF4J 才会输出完整的 Caused by 堆栈，你能看到 “invalid CEN header” 紧跟在哪一行 new ZipInputStream(...) 后面，方便定位是哪个环节出的问题。

确认损坏后，安全清理 + 自动恢复

一旦确认是真损坏，下一步不是报错退出，而是自动兜底：

• 用 Files.deleteIfExists(path) 删除损坏 ZIP，比 File.delete() 更健壮
• 若删除失败（如文件正被占用），最多重试 3 次，每次间隔 100ms；失败则记录 WARN 日志
• 同步清理关联解压目录（如 archive.zip.extracted/），防止残留脏数据干扰下次操作
• 触发重下载逻辑（例如提交到线程池），并设最大重试次数（如 2 次），避免无限循环