Java解压RAR三大技术路线与选型避坑指南

1. 为什么"解压RAR"在Java里是个容易被低估的活儿

先说结论：如果你在项目里接到"支持上传RAR压缩包并自动解压"这类需求，别急着写代码，先花十分钟把技术路线选对，否则后面返工的概率非常高。我见过不少团队在这件事上栽跟头——本地跑得好好的，一上服务器就报错；小文件解压没问题，遇到几GB的分卷包直接卡死；测试环境用得好好的，换台机器就抛NoClassDefFoundError。这些问题根子都不在业务代码，而在于RAR格式的封闭性决定了它在Java生态里没有"标准答案"。

这里得先讲清楚一个前提：ZIP格式是公开规范，JDK自带的java.util.zip包直接就能处理，甚至JDK 7之后还有NIO的FileSystem可以挂载zip当文件系统用。但RAR不一样，它是私有算法，官方只发布了用于解压的免费实现，压缩部分需要商业授权。这个前提直接导致了Java世界里处理RAR的所有方案，本质上都是在调用外部能力——要么用JNI/JNA去调官方提供的动态链接库，要么干脆起一个子进程调用命令行工具，要么依赖第三方纯Java实现（而纯Java实现对RAR5等新版本的支持往往滞后）。

所以本文要聊的"三种方式"，其实是三条截然不同的技术路线，各自对应不同的项目约束：

• 路线一是调用本地解压进程，把系统里安装的解压程序当工具人，Java只负责传参和收结果；
• 路线二是通过JNA桥接官方动态库，让Java直接调用底层函数，性能最好但部署最重；
• 路线三是使用纯Java的第三方库，零外部依赖、纯内存或流式处理，但格式覆盖面和功能完整度要打折。

这三条路线没有绝对优劣，只有场景匹配。你在做的是一个内网的后台批处理系统，服务器环境你可以完全掌控，那路线一最省事；你要做的是一个要分发给几百个客户端的桌面工具，你没法要求用户预装任何东西，那路线三几乎是唯一选择；你要做的是高并发、大文件、单机吞吐要求极高的服务，那路线二的原生调用才有意义。

这篇文章我会把三条路线从原理到落地完整走一遍，包括配置、代码、踩过的坑和最后的选型判断。适合谁看？写过Java、会配Maven、对IO流有基本概念的同学都能跟上。如果你只是想快速跑通一个demo，直接跳到路线三的代码部分抄作业也行，但建议还是把前面的原理和后面的坑看完，能省掉你不少调试时间。

2. 路线一：起子进程调用本地解压程序

2.1 这条路的本质是把RAR当成外部命令来用

Java的ProcessBuilder可以启动任意本地进程，这是最"土"但也最通用的办法。核心思路很直白：目标机器上装好能处理RAR的命令行程序，Java这边拼好命令、设好工作目录、启动进程、监听输出、判断退出码，最后去目标目录里收文件。整个过程中Java完全不需要理解RAR格式，它只是个调度器。

这条路最大的优势是格式兼容性最全。因为解压的活儿是成熟的原生程序干的，RAR4、RAR5、分卷、加密、固实压缩，它支持什么你就支持什么，你不用担心版本兼容问题。第二个优势是实现成本极低，二三十行代码就能跑通，没有额外的jar包依赖，不需要处理本地库的平台适配。第三个优势是内存占用可控，解压过程在独立进程里完成，不会因为一个超大文件把JVM的堆撑爆。

但代价也很明确：你的程序从此依赖运行环境。换台机器没装对应程序，功能直接废掉。这在单体部署、内网服务里不是问题，在做SaaS或者客户端分发时就是硬伤。另外子进程调用意味着你要处理进程管理的问题——超时怎么办、进程挂住怎么办、输出流不读导致缓冲区满死锁怎么办，这些都得自己兜住。

2.2 一个能上生产的调用封装

先看最朴素的版本，再逐步加固。下面这段是基础形态：

public static void unrarByProcess(String archivePath, String destDir) throws Exception { ProcessBuilder pb = new ProcessBuilder(); pb.command("unrar", "x", "-o+", archivePath, destDir + File.separator); pb.redirectErrorStream(true); Process process = pb.start(); try (BufferedReader reader = new BufferedReader( new InputStreamReader(process.getInputStream(), StandardCharsets.UTF_8))) { String line; while ((line = reader.readLine()) != null) { log.debug("unrar output: {}", line); } } int exitCode = process.waitFor(); if (exitCode != 0) { throw new IllegalStateException("解压失败，退出码=" + exitCode); } }

参数解释一下：x是"解压并保留目录结构"，-o+是覆盖已存在文件，路径末尾那个分隔符不能省——加上它表示目标是个目录，不加的话程序可能把最后一个路径段当成文件名，这是很多人第一次踩的坑。

这个版本能用，但离生产还有距离。第一，它没有超时控制。如果压缩包损坏或者进程卡住，waitFor()会一直阻塞，把调用线程彻底挂死。第二，输出流是同步读的，如果解压过程输出特别多（比如几万个文件），读取和进程写之间如果处理不当也可能出问题。第三，命令路径写死了，不同系统、不同安装位置可执行文件名不一样。

加固后的版本应该长这样：

public class LocalArchiveExtractor { private final String executable; private final Duration timeout; public LocalArchiveExtractor(String executable, Duration timeout) { this.executable = executable; this.timeout = timeout; } public ExtractResult extract(Path archive, Path destDir) { if (!Files.isRegularFile(archive)) { return ExtractResult.fail("压缩包不存在: " + archive); } try { Files.createDirectories(destDir); ProcessBuilder pb = new ProcessBuilder() .command(executable, "x", "-o+", "-y", archive.toAbsolutePath().toString(), destDir.toAbsolutePath() + File.separator) .redirectErrorStream(true) .directory(destDir.toFile()); Process process = pb.start(); // 异步消费输出，避免缓冲区写满导致进程阻塞 StringBuilder output = new StringBuilder(); Thread pump = new Thread(() -> { try (BufferedReader r = new BufferedReader( new InputStreamReader(process.getInputStream(), StandardCharsets.UTF_8))) { String line; while ((line = r.readLine()) != null) { if (output.length() < 8192) { output.append(line).append('\n'); } } } catch (IOException ignored) { } }, "unrar-output-pump"); pump.setDaemon(true); pump.start(); boolean finished = process.waitFor(timeout.toMillis(), TimeUnit.MILLISECONDS); if (!finished) { process.destroyForcibly(); process.waitFor(5, TimeUnit.SECONDS); return ExtractResult.fail("解压超时，已强制终止"); } pump.join(2000); int code = process.exitValue(); return code == 0 ? ExtractResult.ok(destDir) : ExtractResult.fail("退出码=" + code + ", 输出=" + output); } catch (Exception e) { Thread.currentThread().interrupt(); return ExtractResult.fail("解压异常: " + e.getMessage()); } } }

几个关键改动值得说透。异步消费输出流是必须的：子进程的标准输出有缓冲区上限，如果父进程不读，缓冲区写满后子进程会阻塞在写操作上，父进程又在等子进程结束，两边互等就是死锁。redirectErrorStream(true)把错误流合并进来，省得开两个线程。超时用waitFor(long, TimeUnit)而不是先sleep再轮询，这是JDK 8就有的阻塞式等待，比轮询干净。destroyForcibly()之后还要再等一次，给操作系统回收进程资源的时间，这一步漏掉的话在Linux上可能留僵尸进程。-y参数是自动应答所有确认提示，不加的话遇到覆盖询问或密码询问，进程会一直等输入，直接超时。

2.3 可执行文件名和退出码这些细节别马虎

不同平台的可执行文件名不一致，这是路线一最容易在部署时翻车的地方。常见情况整理如下：

这就引出一个很实际的建议：别把可执行文件名硬编码，做成配置项或者启动时探测。探测逻辑可以简单点——依次尝试几个候选名，跑一次"打印版本"的命令，能正常返回就用它。这样同一份代码在开发机和服务器上都能工作。

退出码也值得说一下。一般约定 0 是成功，1 是警告（比如有文件被跳过），2 是致命错误，3 是CRC校验失败，7 是命令行参数错误，8 是内存不足，9 是文件创建失败，10 是密码错误。很多实现只判断== 0，把警告当失败处理，导致一些其实已经解压出绝大部分内容的包被判定为整体失败。我的做法是把 0 和 1 都当作可接受，1 的时候记一条警告日志，把输出内容带上，方便事后看是哪几个文件出的问题。

还有一个安全上的细节必须提：解压目标路径要做校验。压缩包里可以包含../这样的路径段，处理不当会被写到目标目录之外的任意位置，这是经典的路径穿越问题。原生程序一般会做防护，但你不能完全指望它。稳妥做法是解压完成后遍历产物，用规范化路径做一次校验：

Path base = destDir.toRealPath(); try (Stream<Path> walk = Files.walk(base)) { walk.filter(Files::isRegularFile).forEach(p -> { try { if (!p.toRealPath().startsWith(base)) { throw new SecurityException("检测到越界文件: " + p); } } catch (IOException e) { throw new UncheckedIOException(e); } }); }

这一段成本很低，但能挡掉一类实在不该出现的事故。

3. 路线二：用JNA桥接官方动态库做原生调用

3.1 什么情况下值得付出部署的复杂度

路线二的门槛明显高一层：你要把官方提供的动态链接库随程序一起分发，要按操作系统和CPU架构准备不同的so/dll/dylib，要通过JNA声明函数签名，要自己管内存分配和释放。听起来很重，那为什么还要用它？

三个典型理由。第一是性能。子进程方案每次调用都有进程创建、动态库加载、文件系统往返的开销，处理大量小压缩包时这部分开销占比很高。原生调用是函数级的，同一个进程内反复调用没有额外成本。第二是控制粒度。原生接口提供回调，你能拿到每个文件的解压进度、原始大小、修改时间、CRC，可以实时上报进度条，可以做解压前后的钩子。子进程方案只能靠解析标准输出里的文字，脆弱且不精确。第三是不受外部程序版本影响。库是随你的程序走的，客户机器上装了什么版本跟你无关，行为完全可控。

反过来说，什么情况下不该用它？你的服务要跑在多种架构混合的集群上、你的交付方式是让客户自己部署到不确定的环境里、你的团队没有精力维护多平台二进制包——这几种情况选路线二都是给自己找麻烦。

3.2 依赖、库文件和函数签名的准备

Maven里加两个依赖，JNA本体和它的平台包：

<dependency> <groupId>net.java.dev.jna</groupId> <artifactId>jna</artifactId> <version>5.14.0</version> </dependency>

如果只是想省事，可以用jna-platform，但通常用不上那么多，本体足够。动态库这边，需要拿到官方提供的解压库文件，按平台分别放进资源目录：

src/main/resources/native/ ├── linux-x86-64/libunrar.so ├── win32-x86-64/unrar.dll └── darwin/libunrar.dylib

这里有个工程上的细节：不要把库文件打到jar里直接读。JNA需要从真实文件路径加载，你得在运行时先把资源流解出来落到临时目录，再指向那个路径。这个"落地"动作要考虑并发和清理，建议在应用启动时做一次，用固定目录而不是每 次都新建临时文件。

接口声明部分，由于原生库的接口面很大，实际项目里通常只声明你真正用到的那几个函数。形状大致如下（函数名和签名以实际库为准，不同版本会有差异）：

public interface UnrarLibrary extends Library { UnrarLibrary INSTANCE = Native.load("unrar", UnrarLibrary.class); // 打开压缩包，成功返回非0 int RAROpenArchiveEx(Structure data); // 处理下一个文件头，返回0表示结束 int RARReadHeaderEx(int handle, Structure header); // 处理当前文件，返回值决定是否继续 int RARProcessFile(int handle, int operation, String destPath, String destName); // 关闭句柄 int RARCloseArchive(int handle); }

结构体用JNA的Structure映射，字段顺序和类型必须和原生定义严格一致，这一点没有任何容错空间——顺序错一位，读出来的就是垃圾数据甚至直接崩掉JVM。所以这部分工作不要凭记忆写，对着头文件逐字段核对，并且写一个小测试先验证"打开压缩包"能返回预期值，再往下做。

3.3 回调、进度与句柄释放的正确姿势

真正让原生方案有价值的是回调。注册一个回调函数，原生库每处理一个文件就调你一次，你能拿到文件名、大小、进度百分比：

public interface Callback extends StdCallCallback { int invoke(Structure msg, NativeLong userData, NativeLong rarError); }

在打开压缩包时通过结构体把回调注册进去。这里有几个坑必须提前知道：

第一，回调线程问题。回调是在原生库的线程上下文里被调用的，如果你在里面直接操作Swing界面或者往一个非线程安全的集合里写数据，会出各种诡异问题。稳妥做法是回调里只做最轻量的事——把进度写进一个AtomicInteger或投递到一个线程安全的队列，由业务线程去消费。

第二，回调返回值的含义。返回非0表示继续，返回0表示请求中断。这个语义要利用起来：用户点了取消按钮，你把一个标志位置为true，回调里检测到就返回0，原生库会优雅停止。这比子进程方案里直接destroyForcibly()要干净得多，不会留下半截文件和句柄泄漏。

第三，异常绝对不能从回调里抛出去。JNA的回调跨越了Java和原生的边界，Java异常没法传给原生侧，抛出去的结果通常是JVM直接崩溃，日志里只有一个看不懂的崩溃记录。所以回调方法体里必须整个包在try-catch里，异常就地吞掉并记录。

第四，句柄必须保证释放。RAROpenArchiveEx返回的句柄对应原生内存和文件描述符，不管成功失败都要在finally里RARCloseArchive。这一条听着简单，实际项目里因为提前return导致句柄泄漏的情况太常见了。写的时候用try-finally或者干脆封装成一个AutoCloseable的包装类，把释放逻辑钉死。

还有一点关于密码处理的：加密包需要先通过RARSetPassword设置密码，这个函数的参数是普通字符串，会以明文形式传进原生层。如果你的场景对安全敏感，要考虑密码来源的合规性，别把密码写在配置文件的明文里。

4. 路线三：纯Java库，零外部依赖的代价与收益

4.1 纯Java实现对RAR的支持边界在哪里

这条路线的吸引力非常直接：一个jar加进来，不依赖任何外部程序，不关心操作系统，不碰原生库，打包分发极其省心。对于要交付给不确定环境的程序——桌面客户端、插件、学生作业、内部小工具——这几乎是唯一现实的选择。

但你必须清楚它的能力边界，否则会在需求评审时给出错误承诺。核心问题在于RAR的压缩算法是私有的，纯Java实现要支持它，只能靠自己逆向或依赖已有的开源实现，而这些实现对格式版本的支持是滞后的。实际使用中会遇到这些情况：

• RAR5格式支持不完整。RAR5是相对新的格式，很多老牌纯Java库对它的支持是后来补的，补得也不全，某些特性（比如特定的压缩方法、大文件的分卷）可能直接抛异常。
• 加密包支持差。RAR的加密涉及密钥派生和特定的加密模式，纯Java库对加密包的支持往往是"能识别但解不开"，或者只支持特定的加密版本。
• 固实压缩包（solid archive）性能差。固实压缩把所有文件当成一个连续流来压，解压时从中间取某个文件需要先解压前面的全部内容。纯Java实现在这个场景下内存占用和解压时间都会比较难看。
• 大文件的内存风险。如果库的API是"一次性返回byte[]"，那一个2GB的包直接把堆干爆。必须确认它提供流式接口。

所以选型时的第一件事不是看 API 好不好用，而是拿你真实的样本包去压测。把线上可能出现的格式都准备一份：RAR4的、RAR5的、带密码的、分卷的、固实的、几GB的大包、文件名带中文和特殊字符的。跑一遍看哪些过哪些不过，这比看任何文档都准。

4.2 流式解压的代码骨架与边界校验

纯Java库的API风格各不相同，但主流形态都是"先打开归档，遍历条目，按条目取流"。下面这个骨架覆盖了最核心的流程，具体类名替换成你选的那个库即可：

public void extractWithJavaLib(Path archive, Path destDir) throws IOException { Path base = destDir.toAbsolutePath().normalize(); Files.createDirectories(base); try (ArchiveInputStream in = openArchive(archive)) { ArchiveEntry entry; byte[] buf = new byte[8192]; while ((entry = in.getNextEntry()) != null) { if (entry.isDirectory()) { continue; } // 关键：规范化后校验，防止路径穿越 Path target = base.resolve(entry.getName()).normalize(); if (!target.startsWith(base)) { log.warn("跳过可疑条目: {}", entry.getName()); continue; } Files.createDirectories(target.getParent()); try (OutputStream out = Files.newOutputStream(target, StandardOpenOption.CREATE, StandardOpenOption.TRUNCATE_EXISTING)) { int n; while ((n = in.read(buf)) != -1) { out.write(buf, 0, n); } } } } }

这段代码里有几个地方是"看起来可有可无，实际少了就出事"的。entry.getName()必须做规范化再校验，因为归档里的条目名是外部可控的，../../etc/passwd这种名字在恶意构造的包里是常规操作。normalize()之后用startsWith(base)判断，能挡住绝大多数穿越尝试。TRUNCATE_EXISTING不能省，如果目标文件已存在且比新内容长，不截断的话会留下旧数据的尾巴，产出一个损坏文件。缓冲区用固定大小循环读写，别用transferTo或者一次读全部——前者在某些库的实现里会因为available()返回不准而出问题，后者直接吃内存。

断点续传的场景要额外注意：解压中断后重跑，已经解出来的文件会被覆盖重写。如果包很大，这个重复劳动很浪费。要优化的话可以在写文件前比较已有文件的大小和条目的声明大小，一致就跳过。但别用时间戳判断，压缩包里的时间戳和文件系统的时间戳精度、时区处理经常会差一点，误判率不低。

4.3 中文文件名乱码：这个坑几乎人人踩一次

RAR里的文件名编码是个历史遗留问题。早期工具在Windows中文环境下用系统默认编码（GBK系）写文件名，后来的工具统一用UTF-8，而格式本身对"这个条目用什么编码"的标识并不总是可靠。结果就是：同一个包，在某些库、某些平台上解出来的文件名是乱码。

排查思路是这样的。第一步，判断是读取阶段错还是写入阶段错：打印entry.getName()的原始字符串，如果打印出来就是乱码，问题在解码；如果打印正常但落到磁盘上变乱码，问题在文件系统的编码处理。第二步，如果是解码问题，看你用的库是否提供编码指定参数——不少库有类似setEncoding("GBK")或构造函数里传字符集的入口。第三步，如果库不支持指定编码，就得自己转换：拿到原始的字节，按候选编码逐个尝试，选那个"转换后能正常显示且能被文件系统接受"的。第四步，如果连原始字节都拿不到，那这个库在你的场景里就是不合适的，换库比改库划算。

有个土办法实测有效：用CharsetDecoder配CodingErrorAction.REPORT，对候选编码做严格解码，解不出来的直接抛异常，这样能自动区分GBK和UTF-8，误判率低很多。但要注意这只能解决大部分情况，真有那种"两种编码都能解出来但内容不同"的极端样本，还是得靠配置指定。

提示：文件名乱码问题不要等到线上反馈才处理。测试用例里必须包含"中文名、日文名、带空格、带括号、超长名"这几类条目，这是最容易暴露编码问题的地方。

5. 三条路线的横向对比与选型决策

5.1 一张表看清成本、能力和风险

前面三条路线各自讲完，现在把它们摆在一起比。选型的时候我习惯按"部署约束、功能要求、性能要求、维护成本"四个维度打分，下面这张表是我自己用的对照：

这张表里我想强调两个容易被低估的项。"故障排查"这一行，原生方案崩溃的时候你拿到的是一个hs_err_pid文件加一堆内存地址，定位成本远高于Java异常；子进程方案虽然土，但输出日志里明明白白写着哪个文件出了什么问题，运维友好度最高。"大文件内存"这一行，很多人以为纯Java库是流式的就一定安全，但如果库内部对固实压缩做了预读缓存，一个几GB的固实包照样能把堆吃掉，这一点必须实测。

5.2 我的实际选择逻辑和一条兜底策略

说点实在的判断经验。项目如果是后台服务、内网部署、机器可控，我基本默认选路线一。原因很简单：投入产出比最高，代码量小，出问题好排查，运维知道怎么装依赖。唯一要补的是超时和进程管理，前面已经写全了。这类项目里追求"零依赖"往往是过度设计。

项目如果是要分发给外部用户的桌面程序，选路线三。用户环境不可控，你不能指望他装任何东西。代价是要在功能上做取舍，产品需求里如果明确要求"支持所有RAR变体"，你得提前跟需求方对齐——不是技术上做不到，是要在包里塞原生库并且维护多平台构建，成本要算清楚。

路线二我只在两种情况下用：一是吞吐确实是瓶颈，实测子进程方案单机每秒只能处理几十个包而上不去；二是产品需要精确到每个文件的进度和取消能力，这是体验上的硬需求。除此之外，它的复杂度不划算。

最后分享一个我常用的兜底策略：主路线加降级。具体做法是把解压能力抽象成一个接口，运行时按配置或环境探测选择实现。默认走纯Java库，遇到它抛"不支持该格式"的异常时，尝试降级到子进程方案。这样客户端小包走快的路径，碰到疑难包自动切到能力更全的路径，两边的优点都拿到了。实现上就是一层策略选择，成本很低，但能显著降低线上"用户传了个特殊包导致功能不可用"的投诉率。

代码形态大致这样：

public interface RarExtractor { void extract(Path archive, Path destDir) throws ExtractException; boolean supports(Path archive); } public class FallbackRarExtractor implements RarExtractor { private final List<RarExtractor> chain; // 按优先级排列 @Override public void extract(Path archive, Path destDir) throws ExtractException { ExtractException last = null; for (RarExtractor e : chain) { if (!e.supports(archive)) continue; try { e.extract(archive, destDir); return; } catch (UnsupportedFormatException ex) { last = ex; // 只在这种异常时降级，其他异常直接抛 } } throw last != null ? last : new ExtractException("无可用解压实现"); } }

注意降级的触发条件要收窄，只在"格式不支持"这类明确的异常上降级。如果对所有异常都降级，一个磁盘满导致的失败会在两条路线上各跑一遍，浪费时间还可能产生半截文件。这个细节不做，兜底策略反而会放大故障影响。

6. 那些文档里不会写的实操教训

6.1 磁盘空间和临时目录，比你想的更容易出事

解压类功能上线后最常见的事故不是代码报错，是磁盘被写满。一个压缩比极高的包，解压后可能是原体积的几十倍，用户传个几百MB的包就能把数据盘塞满，然后整个服务上所有写操作全部失败，影响面远超这一个功能。

防护手段有三个层次。第一层是事前估算：从压缩包头里读声明的解压后总大小，如果超过阈值直接拒绝，这个信息大多数库都能拿到。第二层是事中限制：如果是子进程方案，Linux下可以用ulimit或者cgroup限制；纯Java方案可以在流式读取时累计字节数，超限主动中断并清理。第三层是事后清理：解压产物如果用完就删，一定要在finally里做，并且清理要能容忍文件被占用（Windows下常见），失败时记录下来交给定时任务兜底，别指望一次删干净。

临时目录的选择也有讲究。默认用系统临时目录在容器环境里经常踩坑——容器重启临时目录就没了，或者临时目录挂的是很小的内存盘。建议显式配置一个应用专属的工作目录，随应用的日志目录一起管理，空间和生命周期都可控。

6.2 并发解压时的几个隐蔽冲突

单线程跑得好好的，一上并发就出问题，通常是这几个原因。同名文件互相覆盖：两个请求解压到同一个目标目录，A刚写完B就覆盖，最终产物是两者混杂。解决办法是每次解压分配独立的子目录，用请求ID或UUID命名，完事再按业务逻辑归位。临时文件名冲突：有些库内部会用固定名字的临时文件，并发时会互相踩，这个要查库的文档或者干脆用信号量把这类库的调用串行化。原生库的非线程安全：路线二里那个单例INSTANCE，如果你确认库本身不是线程安全的（多数RAR库都是），就得加锁或者用对象池，别想当然地并发调用。

还有一个容易忽略的：连接池和线程池的占用。解压是典型的IO密集加CPU密集混合任务，一个大包解压可能跑几十秒。如果直接在Web请求线程里同步解压，并发一高线程池瞬间耗尽，整个服务失去响应。正确做法是提交到独立的线程池，接口立刻返回一个任务ID，前端轮询进度。这个改造在功能开发阶段就该做进去，事后补很痛苦。

6.3 校验完整性，别默认解压成功就是文件完好

原生工具和库都会返回成功状态，但"成功"通常只代表流程走完，不代表产物可信。我遇到过磁盘写入异常导致某个文件被截断，退出码依然是0的情况。所以如果这个文件后续要被业务使用，加一层校验很值得：如果包头里有CRC，解压后自己算一遍比对；如果没有，至少校验声明大小和实际大小是否一致。

if (Files.size(target) != entry.getSize()) { throw new IOException("文件大小不符: " + target + ", 期望=" + entry.getSize() + ", 实际=" + Files.size(target)); }

这一行代码的成本几乎为零，但能挡住一类很隐蔽的数据损坏问题。特别是解压后要导入数据库或者做后续计算的场景，一个截断的文件造成的错误数据，排查成本远高于这一行校验。

6.4 关于选型，最后说几句实在的

回到最开始那个判断：这个需求的技术难度不在写代码，在认清约束。你要问自己的问题不是"哪个方案最好"，而是"我的程序跑在什么环境里、能不能控制这个环境、用户会不会传奇怪的包、出问题的时候谁能去排查"。这四个问题的答案基本就决定了路线。

我个人在这些年里的实际体会是：能用简单方案解决的，别上复杂方案。子进程方案被很多人嫌弃"不够优雅"，但它在内网服务场景里的稳定性和可维护性，是原生调用比不了的。反过来，如果你的产品要装到用户机器上，那"优雅"就变成了必需品，只能接受纯Java库的功能妥协。技术选型里最贵的从来不是代码量，是上线之后那些说不清道不明的环境和兼容问题。

最后一个实操小技巧：不管选哪条路线，都在解压前后各记一条日志，带上包名、大小、耗时、条目数、目标目录。这条日志在排查线上问题时价值极高，尤其是那种"用户说解压了但文件不对"的模糊反馈，有了这几个数字，能快速判断是没解、解了一半、还是解到了别的地方。日志成本一分钟，省下的排查时间可能是几小时。