用stat()读取纳秒级mtime：st_mtim.tv_nsec仅在支持纳秒的文件系统（ext4/xfs）上有效，需检查返回值和errno；避免使用struct stat64、std::filesystem::last_write_time()及直接tv_sec*1e9+tv_nsec防溢出。
用 stat() 读取纳秒级 mtime，别信 ctime 或 atime
Linux 下只有 stat() 系统调用能拿到纳秒精度的修改时间（st_mtim.tv_nsec），ctime 是状态变更时间，atime 是访问时间，和“最后修改”无关。glibc 的 struct stat 在支持纳秒的文件系统（ext4、xfs 等）上会填充 st_mtim.tv_nsec 字段，但老内核或某些挂载选项（如 noatime）不影响 mtime 精度。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 必须用
struct stat而不是struct stat64（后者在部分平台不保证纳秒字段存在） - 检查
st_mtim.tv_nsec是否有效：它可能为 0（比如 ext2 或某些 NFS 服务端不支持纳秒） - 不要用
std::filesystem::last_write_time()（C++17）——它只返回std::file_time_type，底层精度取决于实现，GCC libstdc++ 默认截断到秒或微秒，不可靠
stat() 返回值和 errno 判断比 try-catch 更实在
在 C++ 里调用 stat() 是纯 C 风格系统调用，没有异常机制。常见错误不是“没权限”，而是路径不存在、符号链接悬空、或者跨文件系统挂载导致 stat() 失败。直接检查返回值和 errno 最稳。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 始终检查
stat()返回值是否为0；非零就看errno，比如ENOENT（文件不存在）、EACCES（无权限）、ENOTDIR（路径中间某层不是目录） - 别用
throw包一层再 catch——这掩盖了真正的系统错误语义 - 如果路径是相对路径，注意当前工作目录可能被其他线程/信号改变，建议提前用
getcwd()记录或转为绝对路径
纳秒时间戳拼接要防溢出，别直接用 tv_sec * 1000000000LL + tv_nsec
st_mtim.tv_sec 是 time_t（通常是 64 位有符号整数），tv_nsec 是 long（通常 32 位，范围 0–999999999）。直接乘加看似简单，但 tv_sec 很大时（比如公元 2200 年），tv_sec * 1000000000LL 可能溢出 long long。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
std::chrono::time_point表达更安全：std::chrono::seconds(st.st_mtim.tv_sec) + std::chrono::nanoseconds(st.st_mtim.tv_nsec) - 若必须转成整数纳秒，先确认
tv_sec在合理范围内（比如 > 0 && - 注意：
tv_nsec值合法范围是[0, 999999999]，超出说明内核或文件系统返回异常，应视为无效
ext4 默认开启纳秒 mtime，但挂载参数或 mount 选项可能关掉
即使文件系统支持，如果挂载时用了 strictatime 或旧版内核（st_mtim.tv_nsec 也可能恒为 0。这不是代码问题，是环境配置问题。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 运行
mount | grep "$(df . | tail -1 | awk '{print $1}')查看当前挂载参数，确认有没有noatime（不影响 mtime）或relatime（也不影响）——这些都不动 mtime 精度 - 真正影响的是内核版本和文件系统特性：用
tune2fs -l /dev/sdXN | grep "Filesystem features"看是否含ext_attr和large_file，但纳秒支持主要看内核，>=4.18 基本都 OK - 最简验证法：用
touch -d "2024-01-01 12:34:56.123456789" foo && stat -c "%y" foo，如果输出含 9 位小数，说明环境支持
纳秒精度不是写对函数就能拿到的，它卡在内核、文件系统、挂载方式三层之间。哪怕代码完全正确，tv_nsec 仍是 0，先查 stat -c "%y" file 输出，比改代码更快。
