ofstream默认以std::ios::trunc模式打开文件，直接清空并重写；若误加std::ios::in则打开失败且静默，需用fstream实现读写清空；截断不保证原子性与元数据保留。

用 ofstream 清空文件并重写，std::ios::trunc 是默认行为

直接打开 ofstream 并写入，文件内容就没了——只要没加 std::ios::app 或 std::ios::in，std::ios::trunc 就自动生效。不需要显式写出来，也不需要先调用 clear() 或 seekp(0)。

• 默认构造或只传路径的 ofstream 对象，打开即清空（等价于带 std::ios::out | std::ios::trunc）
• 如果显式传了 std::ios::in，哪怕同时写了 std::ios::trunc，在多数标准库实现里也会失败（ofstream 不支持读，std::ios::in 会抑制截断）
• 如果用 std::ios::app，哪怕加了 std::ios::trunc，也无效：追加模式下截断被忽略

ofstream 打开失败却没报错？检查是否误用了 std::ios::in

常见现象是：代码看着清空重写了，但文件内容没变，或者根本没生成新文件。大概率是你写了类似 ofstream f("a.txt", ios::in | ios::out | ios::trunc) 这种组合。

• ofstream 本质是输出流，不支持 std::ios::in；加上它会导致打开失败，f.is_open() 返回 false，但你不检查就直接写，等于什么都没做
• 想“读+写+清空”，该用 fstream，且必须显式指定 std::ios::trunc（因为 fstream 默认既不 trunc 也不 app）
• Windows 下路径含中文或特殊字符时，ofstream 可能静默失败，建议用 f.fail() 或 !f 判断后再操作

需要保留原文件权限或时间戳？std::ios::trunc 做不到

std::ios::trunc 底层调的是系统 open(..., O_TRUNC) 或类似接口，相当于删掉旧内容、从头写——文件 inode 不变，但修改时间（mtime）会更新，权限（mode）保持不变。但它无法保留访问时间（atime），也不能绕过 umask 重设权限。

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

• 真要保留 atime 或精确控制权限，得用系统 API（如 Linux 的 open() + fchmod() + futimens()）
• 跨平台可移植代码里，别指望 ofstream 能做这些事；它只管内容，不管元数据
• 如果只是“清空再写”但不想改时间戳，说明你其实不该用截断，而该用 truncate() 系统调用配合 write()，但这已超出 ofstream 范畴

写入中途崩溃导致文件为空？没有原子性保障

std::ios::trunc 一打开就清空，后续写入是逐步覆盖的。如果程序在写一半时崩溃（比如 SIGKILL、断电），文件就是个截断后未写完的状态——可能为空，也可能只有前几行。

立即学习“C++免费学习笔记（深入）”；

• 这不是 bug，是设计使然：C++ 流不提供事务或原子写入语义
• 安全做法是写到临时文件（如 "file.tmp"），写完 fsync() 或 fflush()，再 rename() 覆盖原文件（Linux/macOS 原子，Windows 需 MoveFileEx()）
• 别依赖 ofstream 析构函数刷盘——它只调 flush()，不保证落盘；close() 也不强制同步，除非你手动 sync_with_stdio(false) 后又调 std::cout.flush()，但这和文件无关

写文件这事，最危险的不是不会用 trunc，而是以为它能兜底——它连写失败都不吭声，更别说崩溃恢复或权限控制。