java中可通过异常链将zipexception作为cause封装进自定义异常，需使用带cause参数的构造函数（如super(message, cause)），避免丢失原始堆栈；日志须用logger.error("msg", e)完整输出链式异常。
Java 中可以通过异常链（exception chaining）将底层的 ZipException 作为 cause 封装进自定义或更高层异常中，从而在解压失败时既保留原始错误信息，又提供更清晰的业务上下文。关键在于使用带 cause 参数的构造函数抛出新异常。
捕获 ZipException 并用异常链包装
在调用 ZipInputStream 或 java.util.zip 相关 API 时，若 ZIP 文件损坏，常会直接抛出 ZipException（它是 IOException 的子类）。此时不要简单吞掉或忽略它，而应将其作为 cause 包装进一个语义更明确的异常中：
- 使用
throw new RuntimeException("解压失败：文件可能已损坏", zipEx); - 或定义业务异常，如
throw new ArchiveProcessingException("无法提取资源 " + entryName, zipEx); - 确保该异常构造函数支持传入
Throwable cause，并调用super(message, cause)
确保异常链完整传递（避免“丢失 cause”）
常见错误是捕获后重新 throw 新异常却不传 cause，导致原始堆栈和错误细节丢失。务必检查：
- 不要写
throw new RuntimeException("解压失败");—— 这会切断链 - 避免用
initCause()手动设置（仅在无参构造后才需，易遗漏） - 优先使用带 cause 的构造方法，JVM 会自动填充
getSuppressed()和getCause()
日志中打印完整异常链
仅靠包装还不够，日志输出必须调用 logger.error("解压异常", e)（而非 e.getMessage()），否则看不到 cause 的堆栈。Log4j / SLF4J 默认会递归打印 cause，包括原始 ZipException 的消息和行号。
例如：WARN 无法读取 entry 'config.json' —— 解压异常：invalid CEN header (bad signature)，后面紧跟着 Caused by: java.util.zip.ZipException: invalid CEN header (bad signature) 及其原始堆栈。
结合 try-with-resources 保证资源释放不干扰异常链
使用 try (ZipInputStream zis = new ZipInputStream(...)) 时，若解压中途抛出 ZipException，且 close() 又抛异常，后者会被 suppress（抑制异常），但原始 ZipException 仍为 cause。可通过 e.getSuppressed() 获取 close 异常，不影响主错误定位。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
