时间戳+文件大小双校验易出错，因内容变更可能不改变二者（如覆盖写入、时钟回拨、relatime机制、NFS挂载不同步等），仅适用于局域网可信本地文件系统且时钟对齐场景；跨平台或网络文件系统必须配合哈希或额外标记。
为什么只比对时间戳和大小容易出错
时间戳 + 文件大小双校验看似简单，但实际同步中会漏掉“内容变了但大小和修改时间没变”的情况——比如文件被覆盖写入相同长度的新内容，或系统时钟回拨导致 mtime 倒退；Linux 上 ext4 默认启用 relatime，频繁读取也可能不更新 mtime。更隐蔽的是 NFS 或某些容器挂载场景下，st_mtime 可能根本不同步。
所以这不是“能不能用”的问题，而是“什么场景下敢信它”。实操建议：
- 仅用于局域网内、可信文件系统（如本地 ext4/xfs）的临时同步，且双方时钟已用
ntpd或chrony对齐 - 若源文件可能被 in-place 修改（如数据库日志、滚动日志），必须加额外保护，比如约定文件写完后 touch 一个
.done标记 - 永远不要在跨平台（Windows ↔ Linux）或网络文件系统（SMB/NFS）上单独依赖
st_size+st_mtime
如何用 C++ 跨平台获取可靠的时间戳与大小
C++17 的 std::filesystem 是目前最稳妥的选择，它屏蔽了 stat() 和 GetFileAttributesEx() 的差异，但要注意几个坑：
-
std::filesystem::last_write_time()返回的是file_time_type，不是秒数，直接转time_t需用clock_cast，否则 Windows 下可能截断精度 - 某些旧版 libc++（如 macOS 10.15 自带）对
last_write_time的实现有 bug，返回值恒为 epoch，建议运行时先用已知文件测一下 -
std::filesystem::file_size()在符号链接上默认解引用，如果想跳过软链直接读属性，得先用is_symlink()判断
示例：安全获取两个关键字段
立即学习“C++免费学习笔记（深入）”；
namespace fs = std::filesystem;
fs::path p = "data.log";
if (fs::exists(p) && !fs::is_symlink(p)) {
auto size = fs::file_size(p);
auto mtime = fs::last_write_time(p);
// 注意：这里 mtime 是 file_time_type，别直接 cout
}
增量同步逻辑怎么写才不丢文件也不重复拷贝
核心是维护一个轻量元数据快照（snapshot），不是每次全扫目录，而是对比上次同步记录。关键点不在“怎么比”，而在“比什么”和“怎么存”：
- 快照里必须存绝对路径（或相对于根同步目录的相对路径），不能只存文件名，否则重命名/子目录变动就乱套
- 记录
st_size和st_mtime时，用纳秒级整数（mtime.time_since_epoch().count()）存，避免浮点或字符串序列化引入精度丢失 - 删除操作不能靠“目标有、源没有”就删——得加开关控制，比如只同步新增/更新，不处理删除（
--no-delete语义） - 遇到同名但
st_size不同，直接覆盖；st_size相同但st_mtime新，也覆盖；两者都一样，跳过
注意：Windows 上 last_write_time 默认只有 100ns 精度，但 FAT32 卷只有 2s 精度，此时两个看似相同的 mtime 实际可能跨了秒级，需做 ±1s 容差比较
什么时候必须放弃时间戳+大小，改用哈希
只要出现以下任一情况，就得切到内容哈希（如 xxHash3 或 BLAKE2b）：
- 同步对象包含可执行文件、配置模板、JSON/YAML 配置——这些文件常被工具 in-place 修改，大小不变但语义已变
- 源端是 WSL2 或 Docker volume，宿主机和容器内看到的
st_mtime可能不一致 - 需要支持断点续传或分块校验（比如大文件上传中途失败，下次只传差异块）
哈希不是万能的：小文件（1GB）要流式计算，别一次性 read() 全部进内存。折中方案是——对 1MB 文件只哈希前 64KB + 后 64KB（跳过中间稳定部分，如日志头尾）
真正难的不是代码怎么写，是快照存储格式要不要加密、哈希缓存要不要落盘、并发扫描时如何避免 stat() 风暴——这些细节一旦忽略，同步延迟会从毫秒级变成秒级
