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++20std::format_to）替代std::ostringstream，避免临时 string 分配 - 日志队列用无锁环形缓冲（如
moodycamel::ConcurrentQueue）把格式化和写入解耦：业务线程只负责 push 格式化后的std::string_view，后台线程批量 write - 避免每条日志都调用
std::chrono::system_clock::now()；改用周期性更新的全局时间缓存（误差容忍 100ms 即可） - 如果日志量极大（>10k 条/秒），考虑 mmap 写入 + 自定义缓冲区，绕过 libc stdio 层
真正难的不是轮转逻辑，而是让轮转不打断正常写入流——所有原子操作、状态同步、跨平台路径处理，都在那几行 rename() 和 open() 调用背后藏着。
