增量同步的核心判断依据是上次同步后文件是否被修改过，C++中首选std::filesystem::last_write_time()配合本地元数据（如.sync_meta文件）记录历史时间戳，需用原子写入保障一致性，并严格限定删除范围以防误删。
增量同步的核心判断依据是什么
关键不是“文件变了没”，而是“上次同步后是否被修改过”。C++ 里最直接的依据是 std::filesystem::last_write_time()，配合记录上次同步时间戳（比如存到一个 .sync_meta 文件里）。别用文件大小或内容哈希做默认判断——小改动（如末尾加个空格）会导致全量比对，开销大；而某些编辑器保存时可能重写整个文件但内容不变，last_write_time() 反而更准。
注意：Windows 和 Linux 下 last_write_time() 精度不同（Windows 常为 100ns，Linux ext4 默认 1s），如果两个系统间同步，建议统一用秒级时间戳存储，避免误判。
如何安全读取和更新本地元数据
元数据不能只存在内存里，得落盘，否则程序崩溃就丢状态。推荐用 JSON 或纯文本存最近一次同步的各文件路径 + 时间戳，例如：
{"src/file.txt": 1717023456, "src/log.bin": 1717023459}
写入时务必用临时文件 + 原子重命名，防止写到一半中断导致元数据损坏：
立即学习“C++免费学习笔记（深入）”；
- 写入到
sync_meta.tmp - 调用
std::filesystem::rename("sync_meta.tmp", "sync_meta.json") - 失败时保留旧文件，不覆盖
读取前先检查文件是否存在且可读；解析失败（如 JSON 格式错误）应视为无历史记录，按首次同步处理，不要抛异常中断流程。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
复制文件时怎么避免覆盖正在被写的文件
目标文件可能正被其他进程写入（比如日志文件），直接 std::filesystem::copy() 会破坏数据。正确做法是：
- 先用
std::filesystem::copy_file(src, dst + ".tmp", std::filesystem::copy_options::overwrite) - 再用
std::filesystem::rename(dst + ".tmp", dst)原子替换 - 若
rename失败（如目标被占用），说明有冲突，跳过本次同步并记录警告
Windows 下还要额外检查 dst 是否是目录（is_directory()），否则 rename 会失败；Linux 下同名目录会被覆盖成文件，行为不一致，必须提前判断。
删除操作为什么不能直接用 remove_all()
增量同步中的“删除”是指源端删了、目标端也要删，但必须严格限制范围：只删目标目录下存在、且源目录中已不存在的路径。直接遍历目标目录并 remove_all() 风险极大——万一源路径配置错了（比如少写了 ./），就会清空整个硬盘。
安全做法是：
- 先构建源目录的完整路径集合（递归遍历 + 转为相对路径）
- 再遍历目标目录，对每个路径计算对应源路径
- 仅当该源路径不在集合中，且目标路径不是同步元数据文件（如
.sync_meta），才执行std::filesystem::remove_all()
特别注意：符号链接要单独处理，remove_all() 对 symlink 会删目标而非链接本身，需用 remove()。
真正难的不是 copy 或 delete，而是把“哪些该删、哪些该跳过、哪些该重试”在异常路径下仍然保持语义一致。比如网络挂载点断开、权限不足、跨设备移动失败——这些情况都要留下可恢复的状态，而不是让下次同步从头开始。
