libzip 支持直接流式读取 ZIP 内文件而不落地解压：用 zip_open() 打开，zip_name_locate() 查找路径（注意编码、大小写、无前导/），zip_fread() 循环读取并判断返回值是否为0，最后 zip_fclose() 释放资源。
用 libzip 直接读取 ZIP 内文件流，不落地解压
核心是跳过解压到磁盘这一步，直接从 ZIP 文件中定位并读取目标文件的原始数据流。C++ 本身标准库不支持 ZIP，必须依赖第三方库；libzip 是目前最稳定、跨平台、且支持只读流式访问的方案——它内部用内存映射或分块读取，避免全量解压。
- 确保 ZIP 文件未加密（
libzip对 AES 加密支持有限，传统 ZipCrypto 基本不可靠） - 用
zip_open()打开 ZIP，非zip_source_file_create()那种写入模式 - 用
zip_name_locate()查找文件路径（注意：路径分隔符必须是/，即使在 Windows 上） - 拿到
zip_file_t*后，调用zip_fread()流式读取，不是zip_fopen()后再手动管理缓冲区
zip_fread() 的缓冲区大小和 EOF 判断容易出错
很多人以为 zip_fread() 和 fread() 行为一致，其实它在读到 ZIP 中文件末尾时返回 0，但不置 feof() —— 因为底层不是 FILE*，而是自定义 stream。直接循环读直到返回 0 是对的，但若混用 feof() 就会多读一次或卡死。
- 每次调用
zip_fread()前不必清空缓冲区，返回值就是本次实际读取字节数 - 推荐固定缓冲区大小（如 8192），避免小块频繁调用影响性能
- 读完后必须调用
zip_fclose()，否则句柄泄漏，多次操作后zip_open()可能失败并报ZIP_ER_NOENT - 若目标文件大于内存，别一次性
malloc全部空间，用 vector 动态追加更安全
路径匹配失败？检查 ZIP 内部路径编码和大小写
ZIP 规范允许存储 UTF-8 或 IBM437 编码的文件名，而 libzip 默认按原始字节匹配。如果你用 std::string 传入 "中文/文件.txt"，但 ZIP 里存的是 IBM437 编码的乱码字节，zip_name_locate() 就会返回 -1。
- 用
zip_get_archive_comment()或先用zip_get_num_entries()+zip_get_name()列出所有条目，确认真实路径字符串 - Windows 下生成的 ZIP 常用小写路径，Linux 下可能大小写敏感，
"Data/config.json"和"data/config.json"是两个不同入口 - 路径开头带
/（如"/assets/img.png"）通常匹配不到，ZIP 内路径一般无绝对根 - 某些压缩工具会在目录项末尾加
/，但文件项不加——匹配时别把目录当文件查
为什么不用 minizip 或 zlib 原生接口？
zlib 本身只提供 DEFLATE 压缩算法，不解析 ZIP 格式（比如中央目录、本地文件头、数据描述符这些结构）；minizip 是 zlib 的封装，API 更低层，需要手动解析 ZIP 目录结构才能定位文件——相当于重写半个 libzip。实测中，用 minizip 定位一个文件平均比 libzip 多花 3–5 倍时间，尤其 ZIP 很大时。
立即学习“C++免费学习笔记（深入）”；
-
libzip内部缓存中央目录，zip_name_locate()是 O(1) 字符串哈希查找 -
minizip没有内置路径索引，得顺序扫描整个 ZIP 文件头，遇到坏块还容易崩溃 - CMake 中链接
libzip只需find_package(libzip REQUIRED)，而minizip常要手动管理源码或 patch - 如果项目已用 CMake + vcpkg/conan，优先选
libzip的zip_read()系列函数，不是旧版的unz*前缀 API
真正卡住的点往往不是“怎么读”，而是“怎么确认 ZIP 里那个文件名到底长什么样”——建议先写个最小工具，用 zip_stat_index() 把所有条目名 dump 出来，再对着匹配。路径不对，后面所有优化都白搭。
