std::filesystem跨平台行为不一致需显式处理：目录遍历须手动排序、重命名前需主动检查目标存在性、Windows中文路径须转UTF-8、批量操作应预校验并记录映射以支持恢复。
用 std::filesystem 遍历目录时 Windows 和 macOS/Linux 行为不一致？
直接用 std::filesystem::directory_iterator 在不同平台下默认排序顺序不同（Windows 通常按文件系统顺序，Linux/macOS 按字典序），导致批量重命名结果不可预测。必须显式排序。
实操建议：
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 遍历后统一存入
std::vector，再用std::sort+std::filesystem::path::filename()排序，确保跨平台一致性 - 避免依赖迭代器隐式顺序；尤其当用户期望“按文件名字母顺序重命名”时，不排序等于行为失控
- 注意
std::filesystem::path的c_str()返回值生命周期短，别存裸指针
重命名前必须检查目标路径是否已存在，否则 std::filesystem::rename 在不同平台报错不同
Windows 下若目标已存在，std::filesystem::rename 抛 std::filesystem::filesystem_error，错误码为 std::errc::permission_denied；Linux/macOS 则是 std::errc::file_exists。不能只靠异常类型判断。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 重命名前先调用
std::filesystem::exists(target_path)主动检查 - 若存在，根据策略决定跳过、覆盖（需额外调用
std::filesystem::remove）或报错退出 - 不要捕获异常后仅打印
e.what()—— 不同平台消息格式差异大，无法可靠解析
Windows 下中文路径传给 std::filesystem 失败？得用 UTF-8 字符串 + 编译器适配
MSVC 默认宽字符接口，但 std::filesystem 要求传入 UTF-8 编码的 std::string；若源字符串是 GBK 或直接从控制台读入，会解析失败，报 std::errc::invalid_argument。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 所有路径输入（如命令行参数、配置文件读取）统一转为 UTF-8：
– Windows 上用WideCharToMultiByte(CP_UTF8, ...)转换宽字符串
– 或直接用GetCommandLineW()+ 手动 UTF-8 转码（比argc/argv可靠） - Clang/GCC 用户：编译加
-finput-charset=UTF-8 -fexec-charset=UTF-8 - MSVC 用户：项目属性 → “高级” → “字符集” 设为“使用 Unicode 字符集”，并在代码开头加
#define _CRT_SECURE_NO_WARNINGS防止 fopen 等警告干扰
批量重命名中途出错，怎么保证原子性或可恢复？
没有真正的原子重命名组操作。一旦第 5 个文件失败，前 4 个已改名，状态不一致。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 预生成全部新路径，提前校验合法性（长度、非法字符、是否冲突），任一失败则整个批次中止，不改动任何文件
- 如需容错，记录原始名→新名映射到临时 JSON 文件（用
nlohmann::json或手写简单格式），出错时靠它反向还原 - 禁止在循环里边 rename 边更新计数器——应先 collect 所有目标路径，再统一执行 rename，便于调试和加 dry-run 模式
std::filesystem 调用前后插桩检查——否则 macOS 测试通过，发给 Windows 用户就卡在第一个中文文件夹上。 
