minizip读取内存ZIP流需用unzOpen2+自定义zlib_filefunc_def，重写open/read/close/seek四函数操作内存数据；文件大小不准因本地头缺失，须遍历匹配；解压需手动分配足够缓冲区并用vector接收二进制数据。
minizip 读取内存 ZIP 流时，unzOpen 直接失败
根本原因是 unzOpen 默认只接受文件路径，不支持内存数据。它底层调用 fopen，传入内存地址会直接返回 NULL，后续所有操作都崩在第一步。
必须改用 unzOpen2 + 自定义 zlib_filefunc_def，把 ZIP 数据当作“虚拟文件系统”注入。核心是重写四个函数指针：open_file_func、read_file_func、close_file_func、seek_file_func，让它们操作你手里的 std::vector<uint8_t></uint8_t> 或 const uint8_t*。
-
open_file_func不真打开文件，只返回一个伪句柄（比如void*指向你的数据起始地址） -
read_file_func从当前偏移开始拷贝数据，更新内部偏移量 -
seek_file_func必须支持SEEK_SET和SEEK_CUR，否则unzLocateFile会失败 - 别漏掉
close_file_func，哪怕它什么也不做——minizip 会在关闭时调用它，空指针会 crash
定位目标文件名后，unzGetCurrentFileInfo 返回的大小不准
常见现象是 unzi64_file_info.uncompressed_size 显示 0 或远小于实际内容，导致 unzReadCurrentFile 读不到东西。这不是 bug，而是 ZIP 中某些压缩方式（如 Deflate64、BZIP2）或 ZIP64 扩展下，本地文件头未完整写入 size 字段，必须依赖中央目录。
解决方案是：先调用 unzGoToFirstFile，再循环用 unzGoToNextFile 配合 unzGetCurrentFileInfo 匹配文件名；不要依赖首次 unzLocateFile 后的 info，它可能没刷新完整元数据。
立即学习“C++免费学习笔记（深入）”；
- 用
unzLocateFile只作快速跳转，之后立刻跟一次unzGetCurrentFileInfo - 检查
unzi64_file_info.size_file_comment是否非零——如果注释区被误当内容读，也会导致错觉 - 若 ZIP 由某些旧工具生成（如早期 Python
zipfile），可能缺 central directory offset，此时需 fallback 到遍历所有文件
unzReadCurrentFile 读出乱码或截断
本质是解压缓冲区没配对：minizip 不自动分配内存，你得自己 malloc 一块足够大的 buffer，并确保大小 ≥ uncompressed_size（从 unzGetCurrentFileInfo 获取）。如果 buffer 太小，它只填满你给的空间，不报错、不提示、不补零。
更隐蔽的问题是字符编码：ZIP 规范本身不存编码信息，文件名用 CP437 或 UTF-8（取决于 general purpose bit 11），但内容体是原始字节流——你拿到的是二进制数据，不是字符串。当成 std::string 直接打印，遇到 \0 就截断。
- 用
std::vector<uint8_t></uint8_t>接收，别用std::string（除非你确认内容是纯 ASCII/UTF-8 且无嵌入 null） - 读取前调用
unzOpenCurrentFilePassword（即使无密码），否则部分 ZIP 会拒绝解压 - 读完务必调用
unzCloseCurrentFile，否则下次unzOpenCurrentFile可能失败
Windows 下中文路径文件名显示为问号或乱码
minizip 本身不处理宽字符，unzGetCurrentFileInfo 返回的 szFileName 是 char*，如果 ZIP 打包时用了 UTF-8 但 Windows 控制台默认 GBK，就会显示异常。这不是读取失败，是终端渲染问题。
真正影响逻辑的是文件名匹配：用 unzLocateFile 查找 "测试.txt" 时，如果 ZIP 里存的是 UTF-8 编码的 bytes，而你传入 GBK 编码的字符串，就永远找不到。
- 统一用 UTF-8 处理文件名：编译时加
/utf-8（MSVC）或-finput-charset=utf-8（GCC/Clang） - 运行前调用
SetConsoleOutputCP(CP_UTF8)和SetConsoleCP(CP_UTF8)，让 cmd 正确显示 - 最稳妥方式：不依赖文件名字符串匹配，改用遍历 + CRC32 校验（
unzi64_file_info.crc）定位目标文件
内存 ZIP 解压真正的难点不在 API 调用顺序，而在数据生命周期管理——你的内存块必须在整个 unzFile 生命周期内有效，释放早了会 segfault，不释放又 leak。别把它当成普通函数调用，得当做一个需要手动托管资源的对象来对待。
