文件操作几乎是每个C++项目都绕不开的功能，而一旦把文件读写和异常处理放在一起，事情就变得棘手了。最典型的场景是：函数里用fopen打开文件，写入过程中某个操作抛出异常，函数提前返回，fclose永远不会被执行，文件句柄就此泄漏。单个句柄泄漏看起来无害，但如果这段代码运行在一个长期驻守的服务进程里，文件描述符迟早耗尽，最终整个进程打开任何文件都会失败。本文将从原理和实例两个层面，讲清楚如何写出异常安全的文件操作代码。
为什么传统C风格文件操作容易泄漏
先看一段典型的C风格写法，这段代码在正常路径下没有任何问题：
bool saveData(const char* path, const std::vector<char>& data) {
FILE* fp = fopen(path, "wb");
if (fp == nullptr) {
return false;
}
// 写入过程可能抛出异常，比如 data 为空时自定义校验抛出
if (data.empty()) {
throw std::invalid_argument("data is empty");
}
size_t written = fwrite(data.data(), 1, data.size(), fp);
if (written != data.size()) {
fclose(fp); // 手动补救，正常路径勉强能覆盖
return false;
}
fclose(fp);
return true;
}这段代码的问题在于，资源的获取和释放分散在多个出口上。一旦中间插入一个可能抛出异常的调用，比如上面的throw std::invalid_argument，程序会立刻离开当前函数，fclose那几行全部被跳过。这就是所谓的手动资源管理困境：出口越多，遗漏的概率越大。
更隐蔽的情况是间接调用。你写的时候以为中间只有fwrite，半年后有人往函数里加了一行日志，而日志库的某个接口在极端情况下会抛异常。这时泄漏就悄悄发生了，而且很难在代码评审中发现。资源泄漏的本质不是粗心，而是把资源生命周期绑定在了执行路径上，而异常恰恰会打断执行路径。
RAII机制：把资源生命周期绑定到对象
解决这个问题的标准答案是RAII，即资源获取即初始化。核心思路是：把资源（这里是FILE*句柄）封装进一个对象，在构造函数中获取，在析构函数中释放。由于C++保证栈上的对象在离开作用域时（无论正常返回还是异常导致的栈展开）析构函数一定会被调用，资源释放就变成了编译器保证的行为，不再依赖程序员记得写fclose。
标准库已经提供了现成的RAII封装，就是std::fstream系列。上面的代码改写后如下：
void saveData(const std::string& path, const std::vector<char>& data) {
if (data.empty()) {
throw std::invalid_argument("data is empty");
}
std::ofstream out(path, std::ios::binary);
if (!out) {
throw std::runtime_error("cannot open file: " + path);
}
out.write(data.data(), static_cast<std::streamsize>(data.size()));
// 即使 write 内部触发异常，out 的析构函数也会关闭文件
if (!out) {
throw std::runtime_error("write failed: " + path);
}
}注意这里的顺序调整：参数校验放在打开文件之前，可以让异常抛出时根本没有资源需要释放。这也是异常安全设计的一个通用技巧——把可能抛出异常的操作尽量前置，把资源获取放在最后。
如果因为性能或接口限制必须使用C风格的FILE*，可以借助std::unique_ptr配合自定义删除器，同样能获得RAII保护：
struct FileCloser {
void operator()(FILE* fp) const noexcept {
if (fp != nullptr) {
std::fclose(fp);
}
}
};
using FilePtr = std::unique_ptr<FILE*, FileCloser>;
void processFile(const char* path) {
FilePtr fp(std::fopen(path, "rb"));
if (!fp) {
throw std::runtime_error(std::string("open failed: ") + path);
}
char buf[4096];
size_t n;
while ((n = std::fread(buf, 1, sizeof(buf), fp.get())) > 0) {
handleChunk(buf, n); // 即使这里抛异常，fp 析构时仍会 fclose
}
}关键点有两个：一是删除器的operator()标记为noexcept，因为unique_ptr的析构函数要求删除操作不抛异常；二是访问原始指针时使用get()而不是release()，后者会交出所有权，等于放弃了自动释放。
异常安全等级与写临时文件的技巧
只保证不泄漏资源是最低要求，也就是所谓的基本异常保证：异常发生时程序处于合法状态、资源不泄漏，但数据可能处于中间状态。对文件操作来说，更强的需求往往是强异常保证——要么完整成功，要么完全没发生过。比如写配置文件，如果写一半失败，留下一个残缺文件，下次启动程序读到坏数据，后果比写失败本身更严重。
实现强异常保证的经典做法是写临时文件加原子替换：先把数据完整写入同目录下的临时文件，全部成功后再调用rename替换目标文件。rename在同一文件系统上是原子操作，要么成功替换，要么目标文件原封不动。示例代码如下：
#include <cstdio>
#include <fstream>
#include <stdexcept>
#include <string>
void atomicSave(const std::string& path, const std::string& content) {
std::string tmp = path + ".tmp";
{
std::ofstream out(tmp, std::ios::binary | std::ios::trunc);
if (!out) {
throw std::runtime_error("cannot create tmp: " + tmp);
}
out.write(content.data(), static_cast<std::streamsize>(content.size()));
out.flush();
if (!out) {
out.close();
std::remove(tmp.c_str());
throw std::runtime_error("write tmp failed");
}
} // 作用域结束，out 已析构并关闭
if (std::rename(tmp.c_str(), path.c_str()) != 0) {
std::remove(tmp.c_str());
throw std::runtime_error("rename failed: " + path);
}
}这里有几个容易踩的坑值得展开。第一，临时文件必须和目标文件在同一个文件系统上，否则rename退化为复制加删除，原子性就没了。第二，写入后要flush并检查流状态，确保数据真正从缓冲区交给操作系统，不能只依赖析构时关闭。第三，失败分支里清理临时文件时要小心，清理动作本身（std::remove）不抛异常，所以放在异常抛出之前执行是安全的。
另一个值得注意的细节是缓冲策略。对关键数据，除了flush还可以考虑fsync级别的同步，C++标准流没有直接暴露这个能力，需要通过fileno拿到文件描述符后调用系统API。这一点在断电场景下尤为重要，毕竟flush只保证数据到了内核缓冲区，不保证落盘。
容易被忽视的陷阱：析构、move与异常规范
有了RAII并不等于万事大吉，还有几个细节会在实际项目中咬人。第一个是析构函数中不要抛异常。栈展开过程中如果某个析构函数抛出异常，而此时已经有一个异常在传播，程序会直接调用std::terminate。所以文件包装类的析构函数必须标记为noexcept，关闭失败时只能记录日志，不能抛出。
第二个是move语义。RAII类如果不处理move，对象被移动后原对象的析构函数仍会执行，可能造成二次释放。自己写文件包装类时，要么删除拷贝并正确定义移动构造，要么直接用unique_ptr这种已经处理好所有权的组件。看一个典型错误：
class BadFile {
FILE* fp_;
public:
explicit BadFile(const char* path) : fp_(std::fopen(path, "rb")) {}
~BadFile() { if (fp_) std::fclose(fp_); }
BadFile(const BadFile&) = delete;
BadFile& operator=(const BadFile&) = delete;
// 没有定义移动构造，被移动后 fp_ 未置空，双重关闭
};
class GoodFile {
FILE* fp_ = nullptr;
public:
explicit GoodFile(const char* path) : fp_(std::fopen(path, "rb")) {}
~GoodFile() { if (fp_) std::fclose(fp_); }
GoodFile(GoodFile&& other) noexcept : fp_(other.fp_) {
other.fp_ = nullptr; // 转移后置空，避免双重释放
}
GoodFile& operator=(GoodFile&&) = delete;
};第三个是异常规范的使用。现代C++推荐默认使用noexcept标注确实不抛异常的函数，特别是移动操作和swap，因为容器在扩容时会优先选择noexcept的移动构造来保证强异常保证。如果文件包装类的移动构造不是noexcept，把它放进std::vector后，扩容时会退化为拷贝，而拷贝又是被删除的，直接导致编译错误或性能回退。
最后总结一下实践清单：文件资源一律用RAII对象管理，优先选择fstream，需要C接口时用unique_ptr加自定义删除器；析构函数和删除器必须noexcept；对数据完整性要求高的写入采用临时文件加原子替换；参数校验和可能抛异常的前置操作放在资源获取之前。做到这几点，文件操作的异常安全基本就有了保障。