zipexception 是故障信号而非容错机制；java 原生 zip api 不支持自动跳过损坏条目，需前置验证文件存在性、魔数及结构完整性，并依 zipfile/zipinputstream 特性选择校验时机，异常捕获仅用于分流决策，真正容错需依赖第三方库或外部校验。
ZipException 不是容错机制，而是故障信号。Java 的 java.util.zip 包本身不提供“自动跳过损坏条目”或“尽力解压”的能力；它一旦发现格式违规（哪怕一个字节偏移错误），就立即抛出 ZipException 终止流程。所谓“通过异常捕获处理损坏”，本质是开发者主动构建的防御层，而非 JDK 内置容错。
损坏检测必须前置，不能依赖解压时的异常
等 ZipInputStream.getNextEntry() 或 ZipFile.getEntry() 抛出异常才反应，往往已错过最佳干预时机。真实场景中应分三步验证：
-
文件存在且非空：检查
file.length() > 0，避免 “zip file is empty” -
魔数校验：读取前 4 字节是否等于
0x504B0304（本地文件头）或用file command确认真实类型 - 结构完整性扫描：对关键 ZIP 结构（如 END header、中央目录偏移）做轻量反向扫描，不加载全量内容即可预判是否可读
ZipFile vs ZipInputStream：损坏暴露时机决定排查效率
两者对损坏的敏感位置不同，选错会掩盖问题根源：
- ZipFile：打开即校验中央目录（CEN），损坏在文件末尾也会立刻失败 —— 适合本地文件，能早发现问题
-
ZipInputStream：只在读到具体 entry 时校验其数据描述符，可能成功读前几个条目后突然崩溃 —— 适合 HTTP 流，但需手动检查
getNextEntry()返回null是否因流提前结束
异常捕获不是修复，而是分流决策点
捕获 ZipException 后，不应只打印日志，而应结合上下文做差异化处理：
- 若来自
new ZipFile(file)→ 基本确认文件物理损坏或非 ZIP 格式，建议直接拒绝并提示用户重传 - 若来自
ZipInputStream的某次getNextEntry()→ 可记录当前 entry 序号，尝试继续读下一个（部分库如Apache Commons Compress支持跳过坏 entry） - 若报错含
invalid CEN header或END header not found→ 高概率是下载截断，应核对Content-Length与实际写入字节数是否一致
真正容错要靠替代方案，不是 try-catch
JDK 原生 ZIP API 没有容错设计。需要鲁棒性时，应切换技术栈：
- 用
net.lingala.zip4j并启用setReadCRC(false)跳过校验（仅限可信来源） - 用
org.apache.commons.compress的ZipArchiveInputStream，配合setIgnoreExtraData(true)和异常后skipToNextEntry() - 对高风险场景（如用户上传），先用系统命令行工具（
unzip -t）做外部校验，再进 Java 流程
