fstream打不开文件主因是路径错误（windows需双反斜杠或正斜杠）和模式误用（ios::in不创建文件而ios::out会）；混用>>与getline易丢数据；二进制操作必须加ios::binary；close()可及时捕获写入失败；多线程须各自独立实例。
fstream 打不开文件的常见原因
直接告诉你：90% 的 fstream 打不开文件，不是代码写错了，而是路径或打开模式没对上。
Windows 下用反斜杠 写路径（比如 "C:datainput.txt"）基本必失败——编译器会把 d、i 当成转义字符。必须写成双反斜杠 "C:\data\input.txt" 或正斜杠 "C:/data/input.txt"。
另一个高频坑：用 ios::in 打开一个根本不存在的文件，is_open() 会返回 false；但用 ios::out 打开不存在的文件，默认会自动创建——很多人误以为“能写就代表打开了”，结果读的时候才发现文件是空的。
- 检查是否调用了
file.is_open()，而不是只看构造函数有没有报错 - 绝对路径优先测试，避免工作目录不明确（VS 默认是项目目录，Clion 默认是可执行文件所在目录）
- Linux/macOS 区分大小写，
"Data.TXT"和"data.txt"是两个文件
读文本文件时，getline 和 >> 的行为差异
operator>> 会跳过开头所有空白（空格、制表符、换行），并停在下一个空白前；getline() 读到换行符为止，且吃掉那个换行符，但不存进字符串。
立即学习“C++免费学习笔记（深入）”；
这意味着：混用两者极易丢数据。比如先用 >> 读一个整数，再用 getline() 读下一行，第二行大概率读到空字符串——因为 >> 停在换行符前，getline() 立刻读到并吃掉它，然后返回空。
- 统一用
getline()处理行输入，需要数字再用std::stoi或std::stringstream转 - 如果必须用
>>，读完后手动调用file.ignore()吃掉残留换行符：file.ignore(std::numeric_limits<:streamsize>::max(), ' ');</:streamsize> -
getline()第三个参数可以指定分隔符，比如getline(file, line, ',')按逗号切字段
二进制读写必须加 ios::binary
不加 ios::binary，在 Windows 上读写二进制文件（比如图片、序列化结构体）会出问题：换行符
可能被悄悄替换成
，导致数据错位、长度变长、校验失败。
尤其注意结构体直接读写：file.write(reinterpret_cast<const char>(&obj), sizeof(obj))</const> 这种操作，必须搭配 ios::binary，否则跨平台完全不可靠。
- 文本模式下，
read()和write()也有效，但语义错乱——别这么干 - 二进制模式下，
seekg()/seekp()的偏移量单位是字节，tellg()返回值可直接用于定位 - 结构体含指针或虚函数时，不能直接二进制读写——那是未定义行为
fstream 对象离开作用域时要不要手动 close()？
不用。析构函数会自动调用 close()，前提是对象正常析构（没被 std::move 走、没抛异常中途跳出）。
但手动调用 close() 有实际价值：能立刻检查是否写入失败。比如磁盘满时，write() 可能不报错，但 close() 会置位 failbit。
- 关键写入后立即
file.close()，然后检查!file或file.fail() - 用 RAII 封装时（如自定义类），在析构里 close 并忽略错误——毕竟那时已无法上报
- 频繁打开关闭小文件比保持打开更慢，但长时间持有一个
fstream对象要注意文件锁和并发风险
真正容易被忽略的是：fstream 不是线程安全的。多个线程共用同一个对象读写，不出错才怪——每个线程该有自己的实例。
