std::filesystem::last_write_time可能不准确，因日志轮转常只改名不更新时间；应优先解析文件名中的时间戳，或用getfiletime验证；跨平台需注意时钟纪元差异与编译器链接问题。
std::filesystem::last_write_time 拿不到正确时间？
Windows 上默认返回的是文件的“最后修改时间”，但日志轮转工具（比如 logrotate 或某些 C++ 日志库）可能只改名不改写时间，导致 last_write_time 依然很新。更稳妥的做法是按文件名里的时间戳解析——比如 app.log.2024-03-15 这类命名。
如果坚持用时间属性，得先确认文件系统是否启用了完整时间精度（NTFS 默认支持，FAT32 会截断到 2 秒），否则 last_write_time 可能偏差达数秒甚至分钟。
- Windows 下用
GetFileTime验证原始时间值，比std::filesystem::last_write_time更底层可靠 - Linux 下注意挂载选项：
noatime不影响last_write_time，但若用了relatime，访问时间可能被延迟更新，不过这和写时间无关 - 跨平台代码中别依赖
file_time_type::clock和system_clock直接互转——C++20 前没标准转换方式，容易溢出或截断
std::filesystem::remove_all 删除失败但没报错？
std::filesystem::remove_all 返回 bool，不是异常驱动；它静默失败很常见，尤其遇到权限不足、文件正被占用、或路径含非法字符（如 Windows 的 CON、AUX）时。
真实场景中，日志目录下常有正在写入的 .lock 文件或未关闭的 .log 句柄，直接删会失败，且 remove_all 不抛异常也不提示原因。
- 删前先用
std::filesystem::status检查是否可写、是否存在、是不是目录 - 对每个待删文件单独调用
std::filesystem::remove，捕获std::filesystem::filesystem_error并打印ec.message() - Windows 下避免递归删符号链接指向的系统目录（比如某日志软链到了
C:\Windows\Temp），remove_all会一路删进去
如何安全判断“一周之前”？
别用 std::chrono::system_clock::now() - 7d 直接减——std::filesystem::file_time_type 和 system_clock 的纪元（epoch）不同，Windows 上差约 11644473600 秒，硬减会得到负时间或极大偏移值。
正确做法是统一转成 time_t 再比：用 std::filesystem::file_time_type 的 to_time_t（C++20 起支持），或通过 clock_cast（C++20）做类型转换。
- C++17 项目只能靠平台 API：Windows 用
FileTimeToSystemTime，Linux 用stat.st_mtim.tv_sec - 注意夏令时：用
gmtime解析而非localtime，避免日期计算错一天 - 日志文件名带 UTC 时间戳时，直接字符串解析比读文件属性更快、更稳
std::filesystem 在旧编译器上链接失败？
Clang 9/GCC 8 默认不链接 stdc++fs，即使头文件能包含，链接阶段会报 undefined reference to 'std::filesystem::...' 。MSVC 2019 16.10+ 才默认启用，之前版本需手动加 /std:c++17 /D _SILENCE_CXX17_FILESYSTEM_DEPRECATION_WARNING。
MinGW-w64 的 std::filesystem 实现不完整，remove_all 对深层嵌套目录可能栈溢出，且不支持符号链接遍历控制。
- GCC 编译加
-lstdc++fs（注意位置：必须放命令行末尾） - CMake 中用
target_link_libraries(myapp PRIVATE stdc++fs)，并检查check_cxx_source_compiles是否通过 - 生产环境建议降级用
boost::filesystem（v1.70+ 完全兼容 C++17 接口），避免编译器碎片问题
真正麻烦的不是删文件，而是删的过程中日志系统还在往同一目录写新文件，或者多个进程同时清理——这时候得加文件锁或原子重命名临时标记目录，否则极易删掉刚生成的日志。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
