不同平台temp_path路径不一致因Windows的GetTempPath返回带反斜杠结尾的路径而POSIX系统不带尾部斜杠，正确做法是使用std::filesystem::temp_directory_path()统一处理。
temp_path 生成的路径为什么在不同平台不一致？
Windows 用 GetTempPath 返回带反斜杠结尾的路径（如 "C:\Users\xxx\AppData\Local\Temp\"），而 POSIX 系统（Linux/macOS）通常返回不带尾部斜杠的 "/tmp"。如果直接拼接文件名，可能得到 "C:\Users\xxx\AppData\Local\Temp\file.txt" 或 "/tmpfile.txt" —— 后者明显错误。
正确做法是统一用 std::filesystem::temp_directory_path()（C++17 起），它已处理平台差异：返回标准化路径（尾部无斜杠），且自动 fallback 到环境变量 TMPDIR/TMP/TEMP 等。
- 别手写
getenv("TMP") + "/myfile"—— 没做路径拼接校验，Windows 下还可能混用'/'和'\' - 避免用
std::filesystem::current_path() / "tmp"—— 这不是系统临时目录，不满足“跨平台可预测”要求 - 若需兼容 C++14，可用 Boost.Filesystem 的
boost::filesystem::temp_directory_path()，行为一致
RAII 清理器为何不能只靠析构函数删除文件？
析构时调用 std::filesystem::remove 看似合理，但实际会遇到三类失败：权限不足（如 macOS 上 /tmp 下某些子目录被 sandbox 限制）、文件正被其他进程打开、或路径已被上层代码提前 remove_all 过。此时抛异常会终止栈展开，导致资源泄漏更严重。
安全做法是：析构函数中静默尝试清理，忽略常见错误；关键逻辑交给显式 release() 方法（主动放弃 RAII 管理权）和可选的 keep()（标记不删）。
立即学习“C++免费学习笔记（深入）”；
- 不要在析构函数里
throw—— RAII 对象常作为局部变量存在，异常会破坏调用栈 -
std::filesystem::remove返回bool，比异常更适合作为清理结果信号 - 构造时若
create_temporary_file失败（如磁盘满），应立即抛异常；但清理失败必须容忍
如何用 std::filesystem::create_temporary_file 实现原子创建？
C++23 引入了 std::filesystem::create_temporary_file，但多数项目仍在用 C++17/20。此时需手动模拟：先用 temp_directory_path() 获取基路径，再用随机后缀（如 std::random_device + base32）生成唯一文件名，最后用 std::filesystem::create_directories（确保父目录存在）+ std::ofstream 配合 std::ios::out | std::ios::trunc | std::ios::binary 打开 —— 关键是加 std::ios::ate 或写入前 seekp(0) 避免空文件残留。
更健壮的做法是使用 open() 系统调用（POSIX）或 CreateFile（Windows）配 O_EXCL | O_CREAT 标志，但这破坏跨平台性。折中方案：
- 用
std::filesystem::path p = temp_dir / ("tmp_" + gen_random_string(8) + ".bin") - 循环 10 次，每次检查
exists(p)，不存在则ofstream(p, ios::out|ios::binary)并立即close() - 若 10 次全失败，抛
std::runtime_error("failed to create unique temp file")
std::unique_ptr + 自定义 deleter 是比 class 更轻量的选择吗？
是，当只需管理单个文件路径字符串、不需额外状态（如是否已清理、是否 keep）时，std::unique_ptr<std::string, void(*)(std::string*)> 配自定义 deleter 更简洁。但它无法支持 release() 或 keep() 语义 —— 因为 release() 后指针为空，deleter 不再触发；而 keep() 需要修改内部状态，unique_ptr 的 deleter 是 const 的。
所以真实项目中，只要涉及“可能中途放弃自动清理”，就必须用完整 class 封装：temp_file 成员变量存 std::filesystem::path 和 bool m_keep = false，析构时仅当 !m_keep && exists(m_path) 才尝试删除。
- 别为了“看起来更现代”强行用
unique_ptr—— 它解决的是动态内存生命周期，不是文件生命周期 - 若用
shared_ptr<temp_file>，注意多个副本共享同一文件路径，析构顺序不可控，可能重复删或删错 - Windows 上还要留意：临时文件被进程内其他线程
OpenFile后，remove可能失败但不影响后续重用 —— 这属于系统行为，RAII 层不必重试
最易被忽略的一点：临时目录本身可能被管理员定期清空（如 Windows 的 Disk Cleanup、macOS 的 tmutil），所以不要假设文件能活过数小时；所有依赖临时文件的逻辑，必须容忍“文件突然消失”，并在读写前用 exists() + is_regular_file() 双检。RAII 清理器只管“我创建的，我尽量删”，不管“系统删没删”。
