应检查 std::ofstream 构造后是否成功：1. 构造时传入路径；2. 用 file.is_open() 或 !file.fail() 判断；3. 避免未检查直接写入。
检查 std::ofstream 构造后是否成功
很多开发者只写 std::ofstream file("path.txt"); 就直接开始 file ，但构造失败（比如路径无权限、目录不存在）时，<code>file 对象处于 failbit 状态，后续写入会静默丢弃数据。
必须在构造后立刻检查：
std::ofstream file("logs/app.log");
if (!file.is_open()) {
// 注意：不是 !file.good()，is_open() 更直接且语义明确
std::cerr << "Failed to open file\n";
return;
}
-
is_open()是最可靠的判断方式；good()在刚构造完也可能是true，但实际没真正打开（比如路径是只读目录下的新文件） - 如果路径含多级目录（如
"logs/2024/06/"），std::ofstream不会自动创建父目录——需提前调用std::filesystem::create_directories()（C++17 起）
每次写入后检查 fail() 或 bad()
即使文件成功打开，写入过程中仍可能失败：磁盘满、权限突变、NFS 挂载断开等。仅靠一次初始化检查远远不够。
关键点：
立即学习“C++免费学习笔记（深入）”；
- 用
fail()捕获格式化失败或流状态异常（如缓冲区写满且刷新失败） - 用
bad()捕获底层 I/O 错误（更严重，通常不可恢复） - 不要只依赖
operator 的返回值——它返回的是流引用，无法直接判错
file << "timestamp: " << now << "\n";
if (file.fail()) {
std::cerr << "Write failed at line " << __LINE__ << "\n";
// 此时可尝试 file.clear() + file.flush() 辅助诊断，但通常应终止写入
}
关闭前必须调用 close() 并检查其返回值
std::ofstream 析构时会自动调用 close()，但这个过程可能失败（比如缓冲区数据写磁盘时出错），而析构函数不抛异常、也不提供错误反馈——失败被彻底吞掉。
显式 close() 是唯一能捕获这类错误的时机：
if (!file.close()) {
// close() 返回 bool：false 表示 flush + system close 均失败
std::cerr << "Close failed — data may be lost\n";
}
- 某些平台（如 Linux）上，
close()失败往往意味着内核已丢弃部分缓冲数据，且无法重试 - 若使用 RAII 自动管理，可在自定义 wrapper 中重载
~wrapper()并记录close()结果到日志或全局状态，但不能依赖它做恢复
用 std::filesystem::space() 预检磁盘空间（可选但实用）
磁盘满是最常见的静默写失败原因。与其等 write 系统调用返回 ENOSPC 再处理，不如提前预警。
示例（C++17）：
namespace fs = std::filesystem;
const auto dir = fs::path("logs").parent_path();
if (fs::exists(dir)) {
auto space_info = fs::space(dir);
if (space_info.available < 10 * 1024 * 1024) { // 小于 10MB
std::cerr << "Low disk space in " << dir << "\n";
// 可触发清理、降级日志级别或切换备份路径
}
}
-
space_info.available是用户可用字节数，比capacity或free更准确（考虑配额、保留块等） - 注意：该函数本身可能失败（如路径不可访问），需用
fs::space(path, ec)版本配合std::error_code检查
真正容易被忽略的是：错误发生后，程序是否还继续用那个已损坏的流对象？一旦 failbit 或 badbit 被置位，所有后续操作（包括 clear() 前的 seekp、flush）都无效。必须先 clear() 才能重试，但重试前得确认根本原因是否可解——比如磁盘满时清空日志再写，比反复 clear() 更有意义。
