std::ofstream::bad() 专用于检测硬件I/O错误（如磁盘满、设备拔出），而 fail() 还包含格式错误等非硬件问题；判断硬件故障必须检查 badbit 或启用其异常，不能仅依赖 fail()。
std::ofstream::fail() 和 std::ofstream::bad() 的区别必须分清
硬件 I/O 错误（如磁盘满、SD 卡拔出、USB 设备断开）在 C++ 标准流中不会抛异常——除非你显式启用了 exceptions()，且只对 std::ios_base::badbit 有效。默认情况下，流只是静默设置状态位。fail() 返回 true 表示 failbit 或 badbit 被置位，但二者含义不同：failbit 多是格式错误（如往 int 写入字符串），badbit 才对应底层读写失败（比如 write 系统调用返回 -1 并设 errno）。所以检测硬件中断，必须检查 badbit，不能只靠 fail()。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 始终在打开文件后调用
ofs.exceptions(std::ios_base::badbit)启用异常（注意：不要加failbit，否则格式错误也会抛异常，干扰 I/O 故障判断） - 若选择不抛异常，则每次写入后立即检查
ofs.bad()，而非ofs.fail() - 写入前确保
ofs.is_open()为 true；但注意：已打开的流在写入中途设备拔出，is_open()仍返回 true，必须靠bad()或异常捕获
Linux 下 write() 返回值和 errno 是更底层的验证依据
标准流封装了系统调用，但有时需要绕过流、直查底层 fd 来确认真实错误类型（比如区分 “No space left on device” 和 “Input/output error”）。C++17 起可通过 std::ofstream::native_handle() 获取 fd，再用 write() 测试。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 仅在
ofs.bad()为 true 后才调用ofs.native_handle()，避免未定义行为（某些平台不支持该接口） - 用
write(fd, "", 0)发送零字节试探——它不改变文件内容，但会触发底层驱动响应；若返回 -1 且errno == EIO，基本可判定硬件故障 - 不要依赖
errno值本身做恢复逻辑（如重试），因为标准流内部可能已多次调用系统调用，errno可能被覆盖；应以流状态为主，errno仅作日志诊断
写入循环中必须每次检查，不能只查末尾
流状态不会自动清除，但也不会“累积”；一次失败后，后续所有操作（包括 flush()、close()）都会立即失败。如果你在循环中批量写入却只在最后检查状态，就可能漏掉中间某次 write 实际已失败，而后续数据被静默丢弃。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 对每个
operator 或 <code>write()调用后，立刻检查ofs.good()或!ofs.bad() - 使用 RAII 封装写入块时，析构函数里调用
ofs.flush()并检查其返回值（flush()失败会置badbit） - 避免把多行写入合并成单个表达式，例如
ofs —— 这样无法定位哪一环出错；拆成独立语句便于插桩和调试
std::ofstream 构造失败 ≠ 硬件 I/O 错误，别混淆初始化与运行时故障
构造 std::ofstream 时传入路径失败（如路径不存在、权限不足），属于打开阶段错误，此时流对象处于 failbit 状态，is_open() 返回 false。这和写入过程中硬件中断是两类问题：前者根本没建立 I/O 通路，后者是通路中途崩断。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 构造后必须检查
!ofs或ofs.fail()，但这时的失败无需查badbit，也不该尝试flush()或close() - 若构造成功但首次写入就
bad()，可能是设备刚插入但未就绪（如 USB 存储未完成初始化），需考虑短延时重试（但最多 1–2 次，避免卡死） - 生产环境建议记录
strerror(errno)（通过std::system_category().message(errno)）并关联时间戳，方便事后区分是瞬时错误还是设备永久损坏
真正麻烦的是那些不报错但数据静默截断的情况——比如 SD 卡在写入一半时掉电，文件系统层可能只刷了部分 buffer，而流对象还显示“good”。这种只能靠校验和或双写日志来兜底，标准流自身无解。
