ZipInputStream 的顺序读取是设计约束而非性能优势，其价值在于内存可控、低启动延迟和流式兼容性，适用于网络流解压、大ZIP处理及OTA等实时场景，但需正确使用缓冲和closeEntry()。
ZipInputStream 的顺序读取模式本身不是性能优势，而是一种设计约束；它带来的实际好处集中在内存可控、低启动延迟和流式兼容性上，但必须配合正确用法才能体现价值。
顺序读取适合流式场景，不依赖文件随机访问
ZipInputStream 不解析 ZIP 中央目录（Central Directory），而是边读边解析本地文件头（Local File Header）。这意味着：
- 它能从网络流、管道或加密传输中直接解压，无需等待整个 ZIP 文件下载完成
- 不需要将 ZIP 元数据一次性加载进内存，对超大 ZIP（如数 GB）或内存受限环境（如 Android 低端设备）更友好
- 适用于“边接收边解压”的实时处理流程，比如 OTA 升级包流式校验与提取
性能关键不在“顺序”，而在“流式控制权在你手上**
它的性能表现高度依赖使用方式，而不是顺序本身：
- ✅ 正确做法：用
transferTo()或带缓冲的循环读取（如 8KB 缓冲区），避免单字节读取 - ✅ 必须调用
closeEntry()，否则后续条目定位失败，引发ZipException: invalid CEN header - ❌ 错误复用：同一个
InputStream多次构造ZipInputStream，会破坏字节偏移，导致解析失败 - ❌ 忽略缓冲：默认内部缓冲区小（通常 512B–2KB），应包装
BufferedInputStream提升吞吐
对比 ZipFile 才能看出适用边界
| 场景 | ZipInputStream 更合适 | ZipFile 更合适 |
|---|---|---|
| 需要反复读取同一 ZIP 的多个不同条目 | ❌（必须重开流，无缓存） | ✅（内置缓存，支持随机访问） |
| ZIP 文件内容可能被外部程序动态修改 | ✅（不缓存中央目录，每次读取都真实） | ❌（缓存可能导致读到旧结构） |
| 解压后只用一次、不关心条目顺序 | ✅（开销低，资源释放快） | ⚠️（打开成本略高，需维护句柄） |
要快速获取某个特定文件（如 META-INF/MANIFEST.MF） |
❌（必须遍历前面所有条目） | ✅（直接 getEntry(name)） |
实际提速建议就三条
- 用
new BufferedInputStream(new FileInputStream(zipPath), 32 * 1024)包装原始输入流 - 解压文件内容时优先用
zipIn.transferTo(fileOut)，避免手动 byte[] 拷贝 - 若需多次访问或查找特定条目，先用
ZipFile读出所需ZipEntry，再用ZipFile.getInputStream(entry)获取其数据流——兼顾随机性与流式解压
不复杂但容易忽略。
