直接用std::ofstream写日志会因磁盘爆满和多进程/线程下删错文件出问题；可旋转日志核心是控制切分时机、命名与旧文件清理；需用单个ofstream成员，先flush再close后open新文件并检查fail()；命名推荐时间戳格式，清理前校验文件类型；多线程必须用mutex串行化全部日志操作。
为什么直接用 std::ofstream 写日志会出问题？
因为日志文件不断追加，磁盘迟早撑爆；手动删旧文件又容易在多线程/多进程下冲突或删错正在写的文件。可旋转日志的核心不是“怎么写”，而是“什么时候切、切到哪、旧文件怎么处理”。C++ 标准库不提供现成方案，得自己控制文件句柄生命周期和命名逻辑。
std::ofstream 怎么安全地切换文件？
关键在“先 close 再 open”，且不能让两个流同时指向同一文件。常见错误是没检查 is_open() 就直接 open()，导致前一个流被悄无声息关闭（析构时可能丢数据）。推荐做法：
- 用一个
std::ofstream成员变量，每次写前检查是否需要旋转（比如大小超限） - 需要旋转时：调用
flush()→close()→ 构造新文件名 →open()，并检查fail() - 避免用
ofstream::open(..., std::ios::app)后再seekp(0, std::ios::end)—— 这在 Windows 下可能因缓存行为不一致而跳过换行
如何命名和清理旧日志文件？
按时间戳（如 "app.log.2024-05-20.001"）比单纯序号更易排查，但要注意跨天时的原子性。别用 std::filesystem::remove_all() 直接删目录，旧文件可能正被其他进程读取（Windows 锁定更严）。稳妥做法：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 生成候选文件列表：遍历当前目录匹配
"app.log.*"，用std::regex提取日期/序号 - 按时间或序号排序，保留最近 N 个（比如
keep_count = 7） - 对要删除的每个文件，先
std::filesystem::status(path).type() == std::filesystem::file_type::regular确认是普通文件，再remove() - 删除失败不 panic，记录一条“无法清理
xxx”的警告即可
多线程环境下怎么避免日志错乱？
不是所有 std::ofstream 实现都保证线程安全写入 —— 即使加锁，也只防住多线程同时调用 operator<<，防不住 rotate() 和写入的竞态。最简方案：
立即学习“C++免费学习笔记（深入）”；
- 所有日志操作（包括 rotate 判断、写入、flush）必须串行化，用同一个
std::mutex - 不要把
std::ofstream暴露给外部，封装成单例类，只暴露log(const char*)这类接口 - 如果性能敏感，可考虑无锁环形缓冲 + 单独日志线程消费，但复杂度陡增，小项目没必要
注意：Windows 上 fopen("xxx.log", "a") 的线程安全性比 std::ofstream 更不可靠，尤其涉及文件重命名时 —— 所以坚持用 C++ 流，别混用 C 文件 API。
