C++ 无法原生实现 ZIP 增量备份，必须依赖 libzip 并自行实现时间戳与 CRC32 双校验逻辑：先用 std::filesystem::last_write_time() 获取纳秒级 mtime，再比对元数据中记录的 mtime 和 CRC32，仅添加/更新变更文件，旧 ZIP 需读取后重建，路径须转正斜杠，索引文件需 fsync 保障一致性。
如何用 libzip 实现带时间戳比对的增量 ZIP 备份
直接结论：C++ 本身不提供 ZIP 增量压缩能力，必须依赖第三方库（如 libzip 或 minizip），且「增量」逻辑需自行实现——核心是比对文件修改时间与上一次备份记录，只添加/更新变更文件，跳过未变项。
关键点在于：ZIP 格式不原生支持「仅追加变更文件并保留旧文件结构」；所谓「增量 ZIP」实际是重建 ZIP + 智能筛选，不是 patch 差分。因此必须维护一份外部元数据（如 JSON 或 SQLite 记录每个文件的 mtime 和 CRC32）。
-
libzip的zip_open()默认以ZIP_CREATE覆盖模式打开，若要复用旧 ZIP 中未变更文件，得先用ZIP_RDONLY打开读取旧条目，再新建 ZIP 写入混合内容 - 不能依赖 ZIP 内部时间戳（
zip_stat_t.mtime）做判断——它可能被压缩工具篡改或精度丢失（秒级），应始终以源文件系统stat.st_mtime为准 - 对软链接、权限位、扩展属性等，
libzip默认不保存，需手动调用zip_file_add()后用zip_file_set_external_attributes()补全
为什么 std::filesystem::last_write_time() 比 stat() 更可靠
C++17 的 std::filesystem 提供跨平台一致的纳秒级修改时间获取方式，避免 stat() 在 Windows（FILETIME）和 Linux（timespec）间手动转换出错。
实操中常见错误是直接比较 file_time_type 对象：它本质是 system_clock::time_point 的别名，但不同平台 epoch 不同，不能裸比较。正确做法是转为 duration 或统一转成 time_t：
立即学习“C++免费学习笔记（深入）”；
auto mtime = fs::last_write_time(path); auto sec_since_epoch = mtime.time_since_epoch().count(); // 纳秒计数，可安全比大小
- Windows 上若路径含中文，
fs::last_write_time()可能抛std::filesystem::filesystem_error，需用fs::u8path()构造路径 - Linux ext4 默认不更新访问时间（
noatime），但修改时间（mtime）始终准确，无需额外配置 - 若备份目标是 NFS 或 SMB 共享卷，
last_write_time()可能因客户端缓存延迟 1–2 秒，建议加 2 秒容差再判定「未变更」
如何避免重复压缩已存在于 ZIP 中的未变更文件
最省资源的做法：遍历源目录时，对每个文件计算 CRC32（非 MD5/SHA），与上次备份元数据中记录的值比对。CRC32 足够快且碰撞概率在单机备份场景下可接受。
不要在每次备份时重新读取 ZIP 文件解压校验——I/O 开销大且无必要。只需维护一个轻量级索引文件（如 backup_20240520.idx），每行格式为：relative/path|mtime_ns|crc32_hex。
- 使用
zlib::crc32()计算时，务必传入初始值0，而非默认的0xffffffff（后者是 gzip 标准，ZIP 使用无符号初始值） - 若文件大于 1GB，边读边算 CRC32 比一次性
mmap更省内存，且可配合std::ifstream::rdbuf()->sgetn()控制缓冲区大小（推荐 64KB） - 遇到硬链接时，
fs::is_regular_file()返回 true，但fs::hard_link_count()> 1，此时应只计算一次 CRC 并复用结果，避免重复 I/O
增量 ZIP 写入时如何处理已删除文件
ZIP 规范不支持「删除条目」操作。若源目录中某文件已被删除，而旧 ZIP 中仍有该条目，则必须重建 ZIP —— 把所有「仍存在且未变更」的文件 + 「新增或变更」的文件写入新 ZIP，跳过已删除项。
这意味着你无法用 zip_replace() 或类似接口就地修改，必须双阶段：第一阶段扫描源目录生成「存活文件集合」，第二阶段创建新 ZIP 并按需添加。临时 ZIP 文件建议用 fs::temp_directory_path() / "backup_XXXXXX.zip"，写完后原子替换（fs::rename()）。
- 若备份过程中源文件被修改，
last_write_time()和 CRC32 可能不一致，应捕获std::ios_base::failure异常并跳过该文件（记日志，不中断整体流程） - ZIP 中路径必须用正斜杠
/分隔，即使在 Windows 上也要把\替换掉，否则部分解压工具（如 macOS Finder）无法识别子目录 - 为防止 ZIP 文件损坏导致全量丢失，建议启用
zip_set_default_password()（如果业务允许加密）或至少用zip_set_archive_comment()写入时间戳和文件总数，便于后续校验
真正难的不是压缩，而是元数据一致性：mtime、CRC、路径映射三者必须严格同步，任一环节脱节就会导致「以为增量实则漏文件」或「反复重压同一文件」。生产环境务必对索引文件做 fsync() 并校验其 SHA256。
