clear() 仅清除流错误状态位，不重置文件指针、不刷新缓冲区、不删除文件内容；需配合 seekg()/seekp() 才能真正重新读写。
为什么 clear() 不等于“清空文件内容”
很多人调用 clear() 后发现文件还是读不到新数据、写不进去，甚至 eof() 依然返回 true——这不是函数没起作用，而是误以为它能重置文件位置或清空缓冲区。clear() 只负责清除流对象内部的错误状态位（如 failbit、badbit、eofbit），它不碰文件指针、不刷缓冲、不删磁盘内容。
常见错误现象：ifstream 读到末尾后再次 >> 失败，调用 clear() 却仍读不出；ofstream 因磁盘满失败后 clear() 就直接继续写，结果静默丢数据。
-
clear()必须配合seekg()或seekp()才能真正“回到前面再读 / 写” - 只调
clear()不重置位置，eofbit很可能立刻又被触发 - 若底层系统调用失败（如
write()返回 -1），badbit被设，此时clear()只是把标志位清了，问题根源（比如文件已关闭）还在
clear() 后必须手动重置文件指针的典型场景
最常踩坑的是反复读同一个 ifstream：第一次读完文件末尾，eofbit 和 failbit 都被置位；clear() 清掉它们后，文件指针仍在末尾，下次读仍立即触发 eofbit。
使用场景：配置文件解析时需多次扫描、单元测试中复用同一文件流、日志回放工具跳转读取。
立即学习 “C++ 免费学习笔记（深入）”；
- 对输入流：
ifs.clear(); ifs.seekg(0, std::ios::beg);—— 先清状态，再回到开头 - 对输出流：
ofs.clear(); ofs.seekp(0, std::ios::beg);—— 注意：若原文件非trunc模式，这不会清内容，只是把写位置挪到开头，后续写会覆盖 - 若要“真正从头开始”，
seekg(0)比seekg(0, std::ios::beg)更安全，避免某些老编译器对枚举值处理异常
clear() 和 ignore() 配合解决缓冲区残留
当用 >> 读数字后跟 getline()，常发现后者读到空行——这不是 clear() 的事，而是换行符还卡在缓冲区里。但一旦因此导致 failbit 被设（比如 getline() 在流已失效时调用），就得先 clear() 才能继续用 ignore()。
性能影响：频繁调 clear() + ignore() 不影响磁盘 I/O，但会多一次缓冲区遍历；ignore(std::numeric_limits<:streamsize>::max(), 'n')</:streamsize> 是标准写法，别漏掉 std::numeric_limits 前缀，否则可能截断。
- 顺序不能错：必须先
clear()（如果流已失效），再ignore() -
ignore()的第一个参数是最大跳过字节数，设太小会漏字符；设std::streamsize(-1)不可靠，不同标准库行为不一 - 若确定只需跳一个换行符，
ifs.get()更轻量，但得自己检查是否成功
跨平台下 clear() 的兼容性注意点
Windows 上用文本模式打开文件，遇到 rn 会被转成单个 n；Linux/macOS 是原样处理。这会导致同一份代码在不同系统上 seekg() 的偏移量与实际字节数不一致——而 clear() 本身没这个问题，但它掩盖了底层不一致引发的后续错误。
错误现象：在 Windows 编译的程序拿到 Linux 生成的日志文件，clear() 后 seekg(100) 定位错乱，读出乱码或提前 eof。
- 二进制模式（
std::ios::binary）下clear()行为完全一致，推荐对非纯文本文件（如序列化数据、图片）强制用 binary - 文本模式下，不要依赖
tellg()/tellp()的返回值做精确字节计算，clear()之后的定位应基于逻辑行号或标记，而非绝对偏移 - MinGW 和 MSVC 对
seekg()在文本模式下的处理略有差异，CI 中建议至少跑一遍 Windows+Linux 双环境验证
真正难的不是调 clear()，而是判断该不该清、清完要不要动指针、动了指针又会不会撞上编码或换行符陷阱。这些细节不报错，但会让程序在某个文件、某台机器、某次部署时突然不工作。
