真实同步必须同时比较文件大小和修改时间戳，并明确主版本源：大小不同必同步；大小相同但源时间更新则同步；两者均相同默认跳过，但需注意硬链接等假一致场景。
为什么不能只比文件大小或只比修改时间
只看 st_size 会漏掉「内容变了但大小没变」的情况，比如把 "hello" 改成 "world"；只看 st_mtime 又容易误判——编辑器保存可能触发时间戳更新但内容未变，NFS 或 FAT32 文件系统还可能丢失秒级精度，导致两个明明不同的文件显示相同时间戳。真实同步必须两者结合，且明确谁是主版本源。
- 大小不等 → 内容必然不同，直接同步
- 大小相等但时间戳不同 → 需进一步判断：以「源端时间戳更新」为同步依据（常见于单向推模式）
- 大小和时间戳都相同 → 默认跳过（但要注意硬链接、挂载点等特殊场景可能造成假一致）
如何用 stat() 安全获取并比较两个文件的元数据
C++ 没有跨平台文件元数据封装，得靠 stat() 系统调用。注意 Windows 下要用 _stat64() 或 GetFileInformationByHandle()，Linux/macOS 用 stat() 即可。关键不是“能不能取到”，而是“取错了字段”或“忽略了时区/精度”。
- 必须检查
stat()返回值，失败时errno才有效，不要假设结构体字段已初始化 - 时间戳用
st_mtime（修改时间），不用st_ctime（状态改变时间），后者在 chmod/chown 后也会变 - Linux 上
st_mtime是time_t，但内核实际支持纳秒级（st_mtim.tv_nsec），不过多数文件系统只存到秒，盲目比纳秒会出错 - 示例判断逻辑：
struct stat src, dst; if (stat("src.txt", &src) != 0 || stat("dst.txt", &dst) != 0) { /* handle error */ } bool need_sync = (src.st_size != dst.st_size) || (src.st_size == dst.st_size && src.st_mtime > dst.st_mtime);
增量同步时怎么避免覆盖新内容或重复拷贝
同步不是“无脑 cp”，而是「按需写入」。最常踩的坑是：用 std::ofstream 直接 open + write，结果目标文件被截断，即使源文件读取失败也已破坏原数据。
- 先写临时文件（如
dst.txt.part），完整写入后再rename()原子替换，避免中间态损坏 - 如果目标文件存在且大小/时间戳都满足跳过条件，立刻 return，不要打开它做任何 I/O
- 不要依赖
fstat()对已打开的 fd 比较——你无法保证 fd 对应的是最新磁盘状态（尤其有 mmap 或 buffer cache 干扰时） - 若需校验写入后一致性，应在 rename 前对临时文件再调一次
stat()，确认大小匹配，再比一次 hash（仅对小文件，大文件跳过）
Windows 下 st_mtime 精度只有 2 秒？怎么应对
是的，FAT32 和部分 SMB 共享卷上，st_mtime 最小粒度是 2 秒，会导致「A 修改后 1 秒同步 B，B 时间戳未更新，下次又同步回来」的震荡。这不是 bug，是设计限制。
立即学习“C++免费学习笔记（深入）”；
- 不要试图用
GetSystemTimeAsFileTime()补精度——它返回的是系统时间，不是文件时间戳 - 实际方案：当检测到源/目标时间戳差值在 ±2 秒内，且大小相同，默认信任源端为最新（适用于 push 场景）；若为 pull 场景，则加一个「最后同步时间戳」本地记录，只同步比该时间新的文件
- 更稳妥的做法是引入轻量级 hash（如 CRC32）缓存，但只对大小相同的文件计算，避免全量扫描开销
同步逻辑越靠近业务语义（比如“这个目录永远由 A 推送”），就越不需要纠结底层精度问题。真正麻烦的从来不是时间戳不准，而是没想清楚谁才是事实来源。
