直接调用 std::filesystem::last_write_time 获取 file_time_type 时间戳，同一体系内可安全比较大小；需捕获 filesystem_error 异常或预检文件存在性，避免转 time_t 以防精度丢失和 epoch 不一致。
用 std::filesystem::last_write_time 获取并比较时间戳
直接调用 std::filesystem::last_write_time 是最简洁的方式，它返回一个 std::filesystem::file_time_type 类型的时间点。这个类型不能直接用 < 比较（不同实现可能用不同时钟），但标准允许在同一体系内比较大小——只要两个文件都在同一台机器、同一进程里读取，就可以安全比。
实操建议：
- 务必检查异常：文件不存在、无权限时会抛
std::filesystem::filesystem_error，建议用try/catch或配合std::filesystem::exists预检 - 不要试图把
file_time_type转成time_t再比——精度可能丢失，且 Windows 和 Linux 的 epoch 偏移不同，转出来可能错乱 - 示例代码片段：
try {
auto t1 = std::filesystem::last_write_time("a.txt");
auto t2 = std::filesystem::last_write_time("b.txt");
if (t1 < t2) {
std::cout << "a.txt 更旧\n";
}
} catch (const std::filesystem::filesystem_error& e) {
std::cerr << "时间获取失败：" << e.what() << "\n";
}
Windows 下用 GetFileTime 但要注意时区与精度陷阱
如果你在写跨平台兼容代码却卡在 Windows API 上，GetFileTime 返回的是 UTC 时间的 FILETIME（100 纳秒单位），但它不自动处理夏令时或本地时区转换——很多人误以为它返回本地时间，结果比对出错。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 用
FileTimeToLocalFileTime后再比：完全没必要，而且引入时区转换误差；两个FILETIME直接按整数比即可（因为都是 UTC） - 忽略
FILETIME是 64 位值，用DWORD截断低/高位导致时间翻转 - 没检查
GetFileTime返回值，句柄无效时返回 false，但变量未初始化就参与比较
正确做法：拿到 ftLastWriteTime 后，用 ULARGE_INTEGER 一次性读成 64 位整数，直接比较数值大小。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
Linux/macOS 下 stat.st_mtim 的纳秒字段别直接用 tv_nsec
POSIX 的 stat 结构体里，st_mtim.tv_sec 和 st_mtim.tv_nsec 是分开的。有人写 if (a.st_mtim.tv_nsec 就下结论，这是错的——必须先比 <code>tv_sec，相等时才比 tv_nsec。
使用场景提醒：
-
st_mtim在 Linux 上是纳秒精度，但实际文件系统可能只支持秒或毫秒（如 FAT32、某些 NFS 配置），此时tv_nsec可能恒为 0 或固定值 - macOS 的
st_mtimespec字段名不同，注意宏判断：#ifdef __APPLE__ - 不要用
ctime()或strftime()格式化后再字符串比较——既慢又易受 locale 影响
跨平台封装时，避免用 system_clock 中转
有人想统一成 std::chrono::system_clock::time_point 方便日志或调试，于是调 std::filesystem::file_time_type → system_clock 转换。这很危险：C++20 规定二者之间转换需通过 clock_cast，而 MSVC 和 libstdc++ 实现不一致，GCC 12 之前甚至不支持 clock_cast。
性能与兼容性影响：
- 转换本身开销不小，尤其在高频比对场景（如 watch 监控）下可测出明显延迟
- 某些嵌入式平台或旧 libc++ 版本不提供
clock_cast，编译直接失败 - 真正需要“显示给人看”的时间，只在最后一步转；比对逻辑全程用原生
file_time_type或原始整数
复杂点往往藏在“看起来一样”的时间类型背后：同一个 file_time_type 值，在不同标准库实现里底层时钟起点可能差几十年，但只要不跨进程、不跨机器，比大小永远可靠——这点容易被忽略。
