is_open() 仅检查流是否关联有效句柄，不检测磁盘满、权限不足等实际I/O错误；需结合fail()、bad()、rdstate()及errno进行健壮错误处理。
用 is_open() 检查文件是否成功打开，但别只信它
is_open() 只反映构造或 open() 调用后“流对象是否关联了有效文件句柄”，不检测磁盘满、权限不足、路径中存在非法字符等实际 I/O 失败。比如在 Windows 上用 std::ifstream f("C:\bad\path\file.txt"); 后 f.is_open() 返回 false，没问题；但若路径合法、目录存在却无读权限，某些标准库实现（尤其旧 MSVC）可能仍返回 true，后续读取时才暴露问题。
- 总是把
is_open()当作“快速初筛”，而非最终判决 - 打开后立刻做一次轻量操作验证，比如
f.peek() != std::char_traits或读一个字节再::eof() unget() - 跨平台项目中，不要依赖
is_open()的返回值做权限/存在性断言
用 fail() 判断读写过程中的逻辑失败，不是所有错误都触发它
fail() 在格式化输入失败（如期望数字却读到字母）、流状态位 failbit 被置位时返回 true，但它**不捕获系统级错误**（如 ENOSPC 磁盘满、EACCES 权限拒绝）。这些错误会让 badbit 置位，此时 fail() 仍为 false，必须用 bad() 或检查 rdstate()。
- 写文件时磁盘突然写满 →
fail()仍为false，但bad()为true - 用
operator>>读整数但遇到空格 →fail()为true，bad()为false - 正确做法：统一用
if (!f) { /* 错误处理 */ }，它等价于(f.fail() || f.bad())
真正健壮的错误检查：结合 rdstate() 和 errno
仅靠 fail()/bad() 无法区分“文件不存在”和“无权限”，因为两者都可能导致 failbit 或 badbit 置位。要定位根本原因，得在 open() 后立刻检查系统错误码。
- Linux/macOS 下：
open()失败后errno有明确值（ENOENT,EACCES,ENOTDIR等） - Windows 下：
_doserrno或调用GetLastError() - C++20 前无标准跨平台错误映射，建议封装一层：打开失败时记录
strerror(errno)或std::system_category().message(errno) - 示例：
std::ifstream f("data.txt"); if (!f.is_open()) { std::cerr
避免 exceptions() 的陷阱：默认不抛异常，开了也未必覆盖所有场景
std::ifstream 默认禁用异常（exceptions(ios_base::goodbit)），即使你手动开启 exceptions(ios_base::failbit | ios_base::badbit)，它仍不会为系统级错误（如 open() 底层 syscall 失败）抛出异常——这些错误发生在流对象构造阶段，异常机制尚未接管。
- 开启异常后，
operator>>格式失败会抛std::ios_base::failure，但open()失败仍静默 - 想统一用异常？必须自己封装
open()调用，并在失败时手动 throw - 生产环境慎用流异常：栈展开可能干扰 RAII 清理，且错误类型单一，不如直接检查状态码信息丰富
事情说清了就结束。最常被忽略的是：打开失败的根源不在 C++ 流层面，而在 OS 系统调用返回值里；is_open() 和 fail() 都只是状态快照，不是错误诊断工具。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
