c++标准流无法捕获扇区损坏异常，必须用posix系统调用：write()后检查eio仅作初步判断，fsync()失败且errno==eio才是坏扇区的可靠信号，close()不可依赖。
写入文件流时根本捕获不到扇区损坏异常
标准 C++ 的 std::ofstream 或 std::fstream 在写入失败时，最多触发 failbit 或 badbit，但这两者对应的是逻辑层错误（如权限不足、路径不存在、缓冲区满），**不是底层磁盘物理错误**。扇区损坏、坏块、固件掉盘等硬件级 IO 故障，通常由内核在驱动层静默重映射、返回成功，或直接触发内核 panic / OOM —— 用户态 C++ 程序根本收不到可捕获的异常。
真正能暴露底层 IO 错误的只有系统调用 + errno
必须绕过 C++ 标准库流封装，改用 POSIX 系统调用（open/write/fsync）并检查 errno 值。关键点：
-
write()返回值为 -1 且errno == EIO：明确表示底层设备报告了不可恢复的 IO 错误（如扇区读写校验失败、SMART 报错后拒绝服务） -
fsync()返回 -1 且errno == EIO：更关键！很多 SSD/HDD 在写缓存未刷盘时掩盖错误，fsync才强制落盘并暴露真实介质问题 -
write()成功但后续fsync()失败，是扇区损坏类问题最典型的信号 - 不要依赖
close()检查：它可能忽略写缓存未刷盘的错误，Linux man page 明确注明 “close()does not flush data to disk”
实际代码中必须显式 fsync + 检查 errno
下面这段才是能发现坏扇区的最小可靠写法（Linux/macOS）：
int fd = open("data.bin", O_WRONLY | O_CREAT, 0644);
if (fd == -1) { /* handle open error */ }
<p>ssize_t written = write(fd, buf, size);
if (written != size) {
if (written == -1 && errno == EIO) {
// ← 这里可能已暴露坏道
perror("write failed with EIO");
}
}</p><p>// 关键：必须 fsync 并检查
if (fsync(fd) == -1) {
if (errno == EIO) {
// ← 真正的扇区损坏大概率在这里被捕获
fprintf(stderr, "fsync failed: physical media error\n");
}
}</p><p>close(fd); // close 前确保 fsync 已完成
</p>
注意：O_SYNC 虽然让 write() 同步落盘，但某些设备固件仍可能延迟报错，fsync() 仍是唯一可信赖的兜底检查点。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
别指望 C++ 异常机制或 std::ios_base::iostate
C++ 流的状态位（failbit/badbit）和异常掩码（exceptions()）完全不感知 EIO。即使你设置 ofs.exceptions(std::ios::failbit | std::ios::badbit)，遇到真实坏扇区也绝不会抛出异常 —— 因为 libc 的 fwrite 内部调用 write() 后若返回 -1 且 errno == EIO，它只会设 __sferror 标志并返回 0，而 C++ 流的 operator 或 <code>write() 成员函数根本不检查这个底层 errno。
更隐蔽的坑：std::ofstream 默认带缓冲，write() 成员函数只写入缓冲区，flush() 也不等价于 fsync() —— 它只清空用户态缓冲，不保证内核页缓存刷到磁盘。
物理扇区损坏的检测本质是“迫使硬件暴露错误”，这只能靠系统调用链路 + fsync + errno == EIO 组合实现；任何试图用 C++ 流抽象层“优雅处理”的方案，都会在坏盘面前彻底失效。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
