std::fstream::exceptions() 默认不抛异常是因为异常掩码为 goodbit，必须在 i/o 操作前调用并设置 failbit | badbit 掩码；eofbit 通常不启用，因读到文件末尾不是错误。
std::fstream::exceptions() 为什么调用后还是不抛异常？
因为默认情况下 std::fstream 的异常掩码是 std::ios_base::goodbit，也就是「完全不抛任何异常」。必须显式设置掩码，且要在流执行任何 I/O 操作之前调用 exceptions()，否则后续失败操作仍静默失败。
- 常见错误：先
open()再exceptions()—— 此时若打开失败，failbit已被置位但没触发异常，之后再设掩码也补救不了 - 正确顺序：构造/声明流 → 调用
exceptions()→ 执行open()或 > - 推荐掩码组合：
std::ios_base::failbit | std::ios_base::badbit（eofbit一般不加入，读到末尾不是错误）
std::fstream exceptions() 的参数到底怎么选？
参数是 std::ios_base::iostate 类型的位掩码，只对「已发生的错误状态」起作用：当流在某次操作后置位了你掩码中包含的状态，就立刻抛 std::ios_base::failure 异常。
-
failbit：格式化失败（如读整数却遇到字母）、open()失败、seekg()越界等逻辑错误 -
badbit：底层读写系统调用失败（如磁盘满、权限不足、文件被另一进程独占锁定） -
eofbit：仅表示读到了 EOF，不是错误；加入掩码会导致每次正常读完都抛异常，几乎不用 - 示例：
fs.exceptions(std::ios_base::failbit | std::ios_base::badbit);
开启 exceptions 后，哪些操作真的会抛异常？
不是所有失败都会触发——只有「修改了流状态」且该状态在掩码中，才会抛。比如 is_open() 返回 false 不抛，但 open() 内部失败并置 failbit 就会抛（前提是提前设好掩码）。
- 会抛异常的操作：
open()、close()（关闭失败时置badbit）、operator>>/getline()（读失败时置failbit或badbit） - 不会抛的操作：
rdstate()、fail()、good()等状态查询函数，它们只是读取状态 - 注意：
operator 对输出流写入失败时，也可能置 <code>badbit并抛异常，但行为依赖底层实现和缓冲策略
std::fstream exceptions() 在 Windows 和 Linux 下有兼容性问题吗？
没有语言级差异，但底层系统错误映射不同，导致实际抛异常的时机和频率略有区别。比如 Windows 上以共享模式打开已被占用的文件，open() 直接失败并抛异常；Linux 默认允许，直到真正 write() 时才可能因 EAGAIN 置 badbit 并抛。
- 性能影响极小：
exceptions()只是设置一个整型掩码，无运行时开销 - 调试友好：比反复检查
if (!fs) { ... }更直接，尤其嵌套读写逻辑中 - 容易忽略的点：异常抛出后流仍处于错误状态，下次操作前需手动
clear()（但通常你该让异常向上冒泡，而不是重试）
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
