应使用std::filesystem::last_write_time()配合clock_cast转system_clock::time_point，再用std::gmtime解析年月；归档前创建目录，跨文件系统移动需检测设备一致性；清理时依据归档路径年月而非文件修改时间。

怎么用 C++ 获取文件的最后修改月份和年份

核心是 std::filesystem::last_write_time() + 系统时钟转换，不能直接读字符串时间。C++20 的 std::chrono 和 std::format（C++23）支持有限，实际项目中更稳妥的是用 std::filesystem::last_write_time() 拿到 file_time_type，再通过 clock_cast 转成 system_clock::time_point，最后用 std::gmtime 或 std::localtime 解析。

常见错误：直接对 last_write_time() 返回值调用 .time_since_epoch().count() 后硬除 1e9 —— 这忽略时区、闰秒和 clock 类型差异，结果可能跨月偏差一天。

• 必须用 std::chrono::clock_cast<:chrono::system_clock>(ft)</:chrono::system_clock> 转换，否则在 Windows（file_time_type 基于 UTC）和 Linux（部分实现基于本地时钟）行为不一致
• 解析时优先用 std::gmtime 避免本地时区夏令时干扰；若业务明确按本地时间归档，再用 std::localtime
• C++17 无原生日期格式化，别依赖 std::put_time —— 它在 MinGW 和某些 libc++ 版本上不可靠，建议手动提取 tm_year（需+1900）、tm_mon（0–11）

如何安全地把文件移动到按年月命名的归档目录

归档本质是原子移动（std::filesystem::rename），不是复制+删源。但前提是目标路径存在且有写权限，否则会抛 std::filesystem::filesystem_error。

典型翻车场景：脚本第一次运行，archive/2024/04/ 目录不存在，rename 直接失败；或目标目录在另一挂载点，rename 退化为复制+删除，中途断电就丢数据。

立即学习“C++免费学习笔记（深入）”；

C++ 算法竞赛自动化测试数据生成与校验框架

根据原题生成新题面、验证器及完整测试数据，自动套用 testlib 模板，用于用户要求生成测试数据时。

下载

• 归档前先用 std::filesystem::create_directories() 创建完整路径，比如 "archive/" + std::to_string(y) + "/" + std::setw(2) + std::to_string(m)
• 跨文件系统移动要检测：比较 std::filesystem::status(src).type() 和 std::filesystem::status(dst_parent).type() 是否同为 directory_file，再用 std::filesystem::equivalent() 判断是否同设备（非 100% 可靠，可辅以 statfs 系统调用）
• 移动失败时，保留原文件，记录日志（含 ec.message()），不要静默跳过

清理过期文件时怎么避免误删“刚归档完”的文件

关键矛盾：归档逻辑按「最后修改时间」分月，但清理逻辑如果也只看修改时间，会导致刚移进 archive/2024/04/ 的文件，因原始修改时间是 3 月，被当成“过期”删掉。

正确做法是清理阶段只检查归档目录内文件的「归档时间」——也就是它在归档目录里的创建时间（std::filesystem::creation_time），但注意：creation_time 在 Linux 上多数文件系统不支持，返回 epoch 时间，不可靠。

• 改用文件路径隐含的时间：归档目录名 archive/2024/04/ 即代表这批文件应保留到 2024 年 4 月之后的 N 个月。例如保留 6 个月，则 2024/04 目录在 2024 年 10 月后可整体清理
• 清理前先遍历归档目录结构，提取年月，计算是否超过阈值（如 current_month - archived_month > keep_months），再递归删除整个目录
• 绝对不要对单个文件做「修改时间 last_write_time，但会重置 last_access_time（且默认关闭），不可依赖

Windows 下用 std::filesystem 遇到权限拒绝或长路径怎么办

Windows 默认路径限制 260 字符，且 std::filesystem 在遇到 ACCESS_DENIED（如系统文件、符号链接指向无权访问目录）时直接抛异常，不提供跳过选项。

这不是 bug，是标准行为。生产环境必须处理，否则脚本扫到 C:Program FilesWindowsApps 就崩。

• 启用长路径支持：在 manifest 中声明 longPathAware=true，或通过组策略开启「启用 Win32 长路径」；代码里用 \? 前缀（如 R"(\?C:path)"）绕过 API 层限制
• 权限错误必须捕获：对每个 directory_iterator 迭代器操作包一层 try/catch，用 std::filesystem::is_directory() 和 std::filesystem::status(path, ec) 检查 ec 而非抛异常
• 跳过符号链接：默认 directory_iterator 不解引用，但 recursive_directory_iterator 会。用 follow_symlinks(false) 构造，避免意外进入受限区域

归档和清理真正难的不是逻辑，是路径边界、时钟精度、跨平台行为差异。写完别急着跑全盘，先拿 archive_test/2023/12/ 这种孤立目录验证一遍创建、移动、清理链路，再放开真实路径。