Java中绕过ZipOutputStream直接用ZLIB压缩需用Deflater/Inflater并禁用ZLIB头：Deflater构造传NO_HEADER，Inflater用setHeaderMode(NO_HEADER)（Java 14+）或new Inflater(true)；必须调用finish()并循环deflate()直至返回值>0，且需手动管理状态机流程。
Java里怎么绕过ZipOutputStream直接用ZLIB压缩？
不能直接调用系统ZLIB库，Java的Deflater和Inflater就是ZLIB的封装，但默认启用了自己的头格式（ZLIB header），不是原始DEFLATE流。如果你要对接C/C++、Python的zlib.decompress()或网络协议里的纯DEFLATE数据，必须关掉ZLIB头。
-
Deflater构造时传Deflater.NO_HEADER，否则输出开头是0x78 0x9c这类ZLIB头字节 -
Inflater初始化时调用setHeaderMode(Inflater.NO_HEADER)（Java 14+才支持）；旧版本只能用反射绕过，或改用new Inflater(true)（true表示兼容GZIP/ZIP头，但对纯DEFLATE不保险） - 注意：
NO_HEADER模式下，Deflater.deflate()可能返回0字节——不是bug，是ZLIB底层未触发flush，得手动deflater.finish()再循环deflate()直到返回值>0
为什么Deflater.setInput()后调用deflate()没输出？
这是最常卡住的地方：Deflater是状态机，不是“喂进去就吐出来”。它内部有压缩缓冲区，setInput()只是把数据存进输入缓冲，不触发压缩。
- 必须显式调用
deflater.needsInput()判断是否需要新数据，再调用deflater.deflate(outputBuf) - 如果输入数据小（比如deflate()返回0——此时要先
deflater.finish()，再持续调用deflate()直到返回值>0或deflater.finished()为true - 别在循环里反复
setInput()同一块byte[]——它会覆盖内部指针，导致上次没处理完的数据丢失
Inflater解压时抛java.util.zip.DataFormatException: invalid stored block lengths
这个错误基本等于“你给的不是合法DEFLATE流”，但原因很具体：
- 常见于用
Deflater压缩时没设NO_HEADER，而Inflater又没配NO_HEADER，头校验失败 - 也可能是数据被截断：DEFLATE流末尾有3字节的“stored block”标记，少一个字节就崩
- 还有种隐形坑：
Inflater默认启用Adler-32校验，但纯DEFLATE流没有校验和——必须初始化时传true（即new Inflater(true)），让它跳过校验 - 别信“自动检测头类型”，
Inflater不会猜，它只按构造参数硬匹配
性能关键：Deflater级别和同步开销怎么选？
Deflater默认是同步的，每次deflate()都锁整个实例，高并发下成瓶颈。但盲目改异步也有代价。
立即学习“Java免费学习笔记（深入）”；
- 压缩级别用
Deflater.BEST_SPEED（1）到Deflater.BEST_COMPRESSION（9），中间值如Deflater.DEFAULT_COMPRESSION（6）更均衡；别无脑用9，CPU翻倍，体积只省5%~10% - 想并发用，别共享
Deflater实例——创建成本不高，复用反而要自己管reset()和线程安全；JDK 17+可考虑Deflater.newInstance()（非public API，慎用） - 大文件压缩务必分块：单次
setInput()别超几MB，否则GC压力大；每块压缩完立刻写磁盘或发网络，别攒全量再处理
ZLIB底层细节藏得深，但核心就两条：头格式必须双方对齐，状态流转必须手动驱动。漏掉finish()或错配NO_HEADER，90%的失败都出在这儿。
