ofstream默认不抛异常，打开失败仅置failbit，需手动检查is_open()或fail()；写入后应显式close()或flush()；中文乱码因编码不匹配，非流本身问题；追加需显式指定ios::app。
ofstream 打开文件失败却不报错？检查 fail() 和 is_open()
默认情况下，ofstream 构造或 open() 失败不会抛异常，而是静默置位 failbit。你调用 operator 写入时可能看似“成功”，实际数据全丢在缓冲区没写进磁盘，还毫无提示。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 创建后立刻检查：
if (!ofs.is_open()) { /* 处理失败 */ }或if (ofs.fail()) { /* 检查错误原因 */ } - 路径含中文、空格、相对路径（如
"./data/output.txt"）容易因当前工作目录不一致导致打开失败；优先用绝对路径验证 - 权限问题常见于 Linux/macOS：尝试写入
/tmp/test.txt排除权限干扰 - 若需异常驱动错误处理，构造前调用
ofs.exceptions(std::ofstream::failbit | std::ofstream::badbit)
写入后文件为空或内容不全？别忘了 close() 或 flush()
ofstream 缓冲写入，析构时自动 close() 并刷新，但若对象生命周期长、或提前退出作用域（比如异常跳出），缓冲区可能未落盘。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 显式调用
ofs.close()是最稳妥的做法，尤其在关键写入后立即确认 - 临时调试可用
ofs.flush()强制刷缓冲，但不关闭文件句柄 - 避免依赖局部对象析构：函数内定义的
ofstream在 return 前已析构，但如果函数被 longjmp 或 signal 中断，行为未定义 - 写入大量数据时，频繁
flush()会显著拖慢性能；批量写完再close()更合理
中文乱码、特殊字符写成问号？编码和流状态要一起管
C++ 标准流本身不处理字符编码转换。ofstream 默认按字节原样写出，乱码本质是源字符串编码（如 UTF-8）与编辑器/终端查看时预期编码不匹配。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 确保字符串字面量编码与源文件保存编码一致（VS Code 记得看右下角显示的编码，推荐 UTF-8 无 BOM）
- Windows 下若用记事本打开乱码，大概率是它把 UTF-8 当 ANSI 解码了；换 VS Code 或 Notepad++ 查看
- 不要对
ofstream调用imbue()试图“设 UTF-8”——标准库无此支持；需要宽字符流（std::wofstream）配合std::codecvt_utf8（C++17 已弃用）或第三方库（如 ICU、utf8cpp） - 简单方案：写纯 ASCII 内容，或接受 UTF-8 字节流，靠外部工具保证查看环境匹配
追加写入老是覆盖开头？std::ios::app 必须显式指定
默认构造或 open("file.txt") 是截断模式（std::ios::out），每次打开都会清空原文件。想追加必须明确告诉流：“我在末尾写”。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 正确写法：
std::ofstream ofs("log.txt", std::ios::app);或ofs.open("log.txt", std::ios::app); -
std::ios::app会强制所有写入定位到文件末尾，即使你调用了seekp()也无效 - 不能混用：
std::ios::app | std::ios::out可以，但std::ios::app | std::ios::in不合法（ofstream不支持读） - 如果需要“先读再追加”，得换用
std::fstream，并手动seekp(0, std::ios::end)
真正麻烦的是跨平台路径拼接和编码隐性依赖——这两处不报错、不崩溃，但一换机器就失效。宁可多写两行 is_open() 检查，也不要赌“本地能跑就行”。
