RAII机制通过栈对象生命周期自动清理临时文件，避免异常退出或未执行main末尾导致的遗漏；TempFileGuard析构时调用remove并检查errno，确保跨平台健壮性。
程序退出前自动删除临时文件，靠的是 RAII 机制——不是靠 atexit 或信号处理，也不是靠手动调用 remove 放在 main 最后，而是把文件路径生命周期绑定到一个栈对象上，析构时自动清理。
为什么不能直接在 main 结尾写 remove
因为程序可能在任意位置异常退出（比如抛出未捕获异常、调用 throw、std::abort），或者被封装在库函数里调用，根本没机会执行到 main 尾部。更常见的是：你写了 remove，但忘了检查返回值，结果文件没删掉还毫无提示；或者路径拼错、权限不足、文件正被其他进程占用，remove 静默失败。
关键点：
-
remove返回int，成功为 0，失败为 -1，必须检查errno才知道原因（如ENOENT、EACCES） - 临时文件路径若含相对路径或未规范化（如
"./tmp/xxx"），在不同工作目录下调用会失效 - 多个线程同时析构同类对象？得加
std::mutex或确保单线程生命周期
TempFileGuard 的最小可行 RAII 封装
核心是构造时记录路径，析构时尝试 remove，且不抛异常（RAII 析构函数应是 noexcept）。不自动创建文件，只管删——避免和文件 I/O 职责耦合。
立即学习“C++免费学习笔记（深入）”；
示例实现：
class TempFileGuard {
std::string path_;
public:
explicit TempFileGuard(std::string p) : path_(std::move(p)) {}
~TempFileGuard() noexcept {
if (!path_.empty()) {
if (remove(path_.c_str()) != 0) {
// 可选：记录日志或忽略，但不要 throw
// errno 可查具体失败原因，如 EBUSY 表示文件正被占用
}
}
}
TempFileGuard(const TempFileGuard&) = delete;
TempFileGuard& operator=(const TempFileGuard&) = delete;
};
使用方式：
- 在作用域开头声明，例如
TempFileGuard guard("/tmp/myapp_12345.tmp"); - 路径建议用
std::filesystem::temp_directory_path()拼接，保证可写且跨平台 - 若需原子创建+自动清理，应在构造函数里调用
mkstemp（POSIX）或CreateTemporaryFile（Windows），再把句柄和路径一起托管
Windows 下 remove 失败的典型场景与绕过方法
Windows 对已打开的文件句柄锁得更死：remove 在文件仍被 std::ofstream 持有、或没调用 .close() 前必然失败，报错 EBUSY（实际是 ERROR_ACCESS_DENIED 映射而来）。
应对策略：
- 确保所有
std::fstream对象在TempFileGuard析构前已离开作用域（即先关流，再析构 guard） - 或改用
std::filesystem::remove（C++17），它对错误码封装更好，且可配合std::filesystem::status提前判断是否可删 - 极端情况（如需强制删正在使用的日志文件），得用 Windows API
DeleteFileW+SetFileInformationByHandle设置删除标记，但普通临时文件不推荐
真正容易被忽略的是：临时文件路径本身可能因程序崩溃而残留，RAII 只保当前运行实例的清理。如果要兜底，得额外加启动时扫描并清理上次遗留的 *.tmp 文件——那已是另一层健壮性设计了。
