C++标准库的std::ifstream/std::ofstream不支持非阻塞I/O，因其封装阻塞式系统调用且不暴露底层文件描述符；需直接使用open()获取fd并配合fcntl()、read()/write()及epoll等机制实现真正非阻塞文件操作。
文件流（std::ifstream/std::ofstream）本身不支持非阻塞模式 —— C++ 标准库的流对象封装了阻塞式系统调用，无法通过 fcntl 或类似方式“打开非阻塞开关”。真正能设为非阻塞的，是底层的文件描述符（int fd），而流对象默认不暴露它。
如何获取并设置底层文件描述符的非阻塞标志
如果你用的是 std::fstream 且构造时传入了已打开的 fd（例如通过 open() 得到），可先用 fileno() 反向提取 fd，再用 fcntl 设置 O_NONBLOCK：
-
std::fstream必须以std::ios::in | std::ios::out方式打开，并且底层 fd 必须是合法、已打开的（不能是流自己内部打开的） - 调用
fileno(fp.rdbuf()->pubsync())不可靠；正确做法是：用open()手动打开文件得到int fd，再用fdopen(fd, "r+")获得FILE*，最后用std::iostream包装（C++23 起支持std::basic_iostream(FILE*)）；但更常见、更可控的是直接操作 fd - 若坚持用
std::fstream，它没有提供访问底层 fd 的标准接口（rdbuf()->native_handle()是非标准扩展，仅 libstdc++/libc++ 部分版本支持，且行为不一致）
为什么不能对普通 std::ifstream("file.txt") 用 fcntl
因为这类流在构造时内部调用 open() 或 fopen()，但 fd 立即被封装进私有缓冲区，对外不可见。即使你事后用 open() 重新打开同一路径，得到的是另一个独立 fd，fcntl 对它生效，但和原流对象完全无关：
- 对原流调用
read()仍会阻塞 —— 它走的是 C++ 缓冲区 + 阻塞式read()系统调用路径 - 试图用
dup()复制流的 fd？不行：std::fstream不提供fd获取入口，dup无从下手 - 结论：想用非阻塞 I/O，就别用
std::fstream做载体；改用裸int fd+read()/write()+fcntl(fd, F_SETFL, flags | O_NONBLOCK)
fcntl 设置 O_NONBLOCK 的典型错误写法
常见误操作不是语法错，而是语义错 —— 比如在错误时机调用、忽略返回值、或混淆 fd 来源：
立即学习“C++免费学习笔记（深入）”；
- 写成
fcntl(fd, F_SETFL, O_NONBLOCK)：错！这会**覆盖**原有标志（如O_RDONLY），应先F_GETFL再按位或：fcntl(fd, F_SETFL, flags | O_NONBLOCK) - 对一个刚
open()返回的 fd 直接fcntl(... F_SETFL ...)却不检查返回值：失败时errno可能是EBADF（fd 无效）或EINVAL（flags 不合法），不检查就继续读写，必出错 - 在
fork()后子进程里修改父进程传来的 fd 标志：可行，但要注意父子进程共享同一打开文件表项，O_NONBLOCK是该表项的属性，改一个，另一个也变 —— 这常被忽略，导致子进程行为意外
真正可用的非阻塞文件读写实践路径
绕过流对象，直击系统调用，才是稳定方案：
- 用
open("path", O_RDWR | O_NONBLOCK)一步到位开启非阻塞（比先open再fcntl少一次系统调用） - 读取时检查
read(fd, buf, size)返回值：>0是成功字节数，0是 EOF，-1且errno == EAGAIN || errno == EWOULDBLOCK表示当前无数据，需稍后重试 - 写入同理：
write()返回-1+EAGAIN/EWOULDBLOCK表示内核缓冲区满，不能强行重试，要配合epoll或轮询判断可写事件 - 注意：普通磁盘文件
read()几乎不会返回EAGAIN（Linux 中常规文件读总是就绪），O_NONBLOCK对磁盘文件意义有限；它主要对管道、FIFO、socket、tty 等设备型 fd 有效
非阻塞真正的复杂点不在设置，而在后续逻辑：你需要自己管理缓冲、重试边界、EOF 判定、以及——最关键的是，必须把 fd 放进 epoll/poll 等多路复用器里等待就绪，否则空转轮询会吃光 CPU。这点，任何流封装都帮不了你。
