C++实现日志滚动保存技巧

std::ofstream直接轮转易丢日志，因close()不保证落盘且多线程下flush()与close()存在竞态；应显式flush、加锁覆盖完整轮转流程、用临时文件原子替换、维护归档列表并异步清理、解耦格式化与IO以提升性能。

为什么 std::ofstream 直接轮转容易丢日志

很多工程实现直接在日志文件达到阈值时关闭旧流、新建文件，但没考虑多线程写入或缓冲区未刷盘的问题。典型表现是：日志刚切到 app.log.1，app.log 末尾几行就没了。根本原因是 std::ofstream::close() 不保证立即落盘，且多线程下 flush() 和 close() 之间存在竞态。

实操建议：

• 每次写入后不依赖自动 flush，显式调用 stream.flush()（但别滥用，会影响性能）
• 轮转前先 stream.flush()，再用 stream.clear() 清除状态位，最后用 stream.open(..., std::ios::out | std::ios::app) 复用对象
• 避免频繁构造/析构 std::ofstream 对象——它内部有缓冲区分配开销
• 轮转操作本身必须加锁，且锁粒度要覆盖“检查大小 → flush → rename → reopen”整个流程

按大小滚动时如何安全重命名正在写的文件

Windows 下直接 rename("app.log", "app.log.1") 会失败（文件被占用），Linux 虽支持，但若其他进程正 fopen("app.log", "a")，行为不可控。更稳妥的做法是写完后原子替换，而非原地 rename。

实操建议：

• 写日志始终往 app.log.tmp 写，定期检查大小；达标后 close() 并 rename("app.log.tmp", "app.log.1")
• 主日志文件永远叫 app.log，只由当前 writer 打开；历史文件用数字后缀，按时间或序号排序归档
• 用 std::filesystem::rename()（C++17）替代 C 风格 rename()，它对路径合法性有基本检查
• 注意：Windows 上 rename() 不能跨分区，如果日志目录挂载在不同磁盘，需改用 std::filesystem::copy_file() + std::filesystem::remove()

logrotate 风格的保留策略怎么在 C++ 里轻量实现

工程中不需要完整复刻 logrotate 的配置语法，但得控制磁盘占用。常见错误是遍历所有 *.log.* 文件再排序删除——IO 开销大，且易受文件系统延迟影响。

实操建议：

• 维护一个固定大小的 std::vector 记录最近 N 个归档文件名（如 {"app.log.1", "app.log.2", ...}），每次轮转时 push_front，pop_back
• 删除动作异步做：轮转完成后发个低优先级任务去删最老的，避免阻塞主线程
• 检查磁盘剩余空间用 std::filesystem::space()，而不是硬编码保留 1GB；低于阈值时主动触发清理
• 归档文件名里嵌入毫秒级时间戳（如 app.log.20240520-142301-123），比纯数字序号更容易调试和排查

性能瓶颈往往卡在字符串拼接和 IO 线程争抢

高并发下，每个日志调用都做 std::to_string() + operator+ 拼接，再进 std::ofstream::write()，CPU 和锁竞争双双拉满。实测显示，格式化耗时可能占单条日志 70% 以上。

实操建议：

• 用 fmt::format_to()（或 C++20 std::format_to）替代 std::ostringstream，避免临时 string 分配
• 日志队列用无锁环形缓冲（如 moodycamel::ConcurrentQueue）把格式化和写入解耦：业务线程只负责 push 格式化后的 std::string_view，后台线程批量 write
• 避免每条日志都调用 std::chrono::system_clock::now()；改用周期性更新的全局时间缓存（误差容忍 100ms 即可）
• 如果日志量极大（>10k 条/秒），考虑 mmap 写入 + 自定义缓冲区，绕过 libc stdio 层

真正难的不是轮转逻辑，而是让轮转不打断正常写入流——所有原子操作、状态同步、跨平台路径处理，都在那几行 rename() 和 open() 调用背后藏着。