精准捕获ZipException需匹配异常消息关键词确认真损坏，如“invalid CEN header”；保留原始异常链封装为业务异常；日志必须输出完整堆栈；损坏确认后安全删除文件并重下载。
捕获 ZipException 本身不难，关键是怎么判断它真是“损坏”，而不是误报或配置问题；怎么在保留原始错误的前提下给出可操作的响应——比如删文件、重下载、换编码。
精准捕获并确认是真损坏
ZipException 是 IOException 的子类，但不是所有 ZipException 都代表文件损坏。要避免误判，得看异常消息里的关键词：
- “invalid CEN header” 或 “invalid LOC header”：中央目录或本地头损坏，基本可断定 ZIP 结构异常
- “zip file is empty” 或 “error in opening zip file”：文件为空、魔数（PK\x03\x04）缺失，大概率下载不完整
- “invalid stored block lengths”：数据块校验失败，常见于传输截断或存储损坏
不要只靠 instanceof ZipException 就行动，建议用 e.getMessage().toLowerCase() 做字符串匹配，更可靠。
保留上下文，别丢原始堆栈
直接 throw new RuntimeException("解压失败") 会切断异常链，丢失关键定位信息。正确做法是用带 cause 的构造函数包装：
立即学习“Java免费学习笔记（深入）”；
- 定义业务异常，如
throw new ArchiveCorruptionException("无法解压资源 " + fileName, e); - 确保该异常类继承自
RuntimeException，且构造函数调用super(message, cause) - 避免手动调
e.initCause()—— 容易遗漏，优先走构造函数传参路径
日志必须打印完整异常链
只写 logger.error("解压失败: {}", e.getMessage()) 是无效的。必须用：
logger.error("解压失败，文件: {}", zipPath, e);- Log4j / SLF4J 会自动递归输出
Caused by:及原始 ZipException 的堆栈和行号 - 这样你才能看到 “invalid CEN header (bad signature)” 后紧跟着哪一行代码触发了 ZipInputStream 构造
损坏确认后执行清理与恢复
捕获并验证是真损坏后，下一步是安全清理 + 自动恢复：
- 用
Files.deleteIfExists(path)删除损坏的 ZIP 文件，比File.delete()更健壮 - 若删除失败（比如文件正被占用），加最多 3 次重试，每次间隔 100ms，失败则记录 WARN 级日志
- 同步清理关联解压目录（如
archive.zip.extracted/），防止残留脏数据干扰下次解压 - 触发重下载逻辑（例如提交到线程池），并设置最大重试次数（如 2 次），避免无限循环
