std::ofstream 直接写日志会卡主线程，因为磁盘 i/o 是阻塞的；应使用专用落盘线程管理文件，避免 logrotate 干预，所有文件名须含毫秒级时间戳，并确保写缓冲、落盘、滚动、压缩四阶段互斥且句柄安全。
为什么 std::ofstream 直接写日志会卡主线程？
因为磁盘 I/O 是阻塞的，哪怕只是 operator 一个字符串，底层仍可能触发同步刷盘（尤其在 <code>std::ios_base::unitbuf 或 std::endl 下）。更麻烦的是，滚动时重命名+压缩（比如调用 gzip）必然涉及系统调用和 CPU 占用，全在日志线程里做，等于把性能瓶颈主动塞进关键路径。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 日志写入必须走无锁环形缓冲区（
boost::lockfree::spsc_queue或自研moodycamel::ConcurrentQueue），生产者（业务线程）只做 memcpy + 原子 push，绝不碰文件句柄 - 单开一个高优先级日志落盘线程，批量消费缓冲区，用
writev()或std::fwrite批量写入，禁用std::endl，改用n - 滚动触发点（如文件大小 >100MB）由落盘线程自己检查，不要让业务线程判断 —— 否则又引入原子读+条件竞争
日志滚动时如何避免 rename() 失败或丢失数据？
Linux 下 rename("app.log", "app.log.20240520-102345.gz") 看似原子，但若目标已存在、跨文件系统、或被杀进程残留句柄，就会失败；更危险的是：压缩过程没结束就切新文件，旧日志可能被覆盖或丢最后一段。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 滚动分三步：1)
close()当前文件句柄 → 2) 启动子进程（fork()+exec("gzip")）异步压缩 → 3) 仅当waitpid()成功后，才rename()原文件为.gz后缀。压缩失败则保留未压缩文件，不删 - 所有文件操作用绝对路径，避免 chdir 导致路径错乱；
open()必须带O_CLOEXEC标志，防止子进程继承 fd - 用
stat()检查目标 .gz 是否已存在，存在则加序号（app.log.20240520-102345.1.gz），别直接覆盖
压缩环节该用 zlib 还是子进程调 gzip？
用 zlib 库（deflate()）能避免 fork 开销，但会吃主线程 CPU；用 gzip 子进程更安全隔离，但启动慢、资源开销大。实际压测发现：单次压缩 10MB 日志，zlib 耗时约 80ms（占用一个核 100%），而 gzip -1 子进程平均 120ms（但 CPU 不抢占主流程）。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 如果日志吞吐极高（>10MB/s），选
zlib，但必须绑定到专用 CPU 核（pthread_setaffinity_np()），并限制压缩级别为Z_BEST_SPEED - 如果更看重稳定性（比如嵌入式或容器环境），坚持用
gzip子进程，且预创建 2–3 个空闲子进程池（posix_spawn()+suspend），避免每次滚动都 fork - 永远不要在压缩过程中关闭原日志文件句柄 ——
gzip需要读取它，提前关会导致read(): Bad file descriptor
logrotate 能不能直接替代手写滚动逻辑？
不能。系统级 logrotate 是定时/按大小触发的外部工具，它发 SIGHUP 让程序重新打开日志文件，但 c++ 程序必须自己处理信号、原子切换 std::ofstream、保证切换瞬间不丢日志 —— 这比手写滚动还容易出竞态。而且 logrotate 压缩是同步阻塞的，照样卡你的 reload 流程。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 关掉
logrotate，别让它碰你的日志目录。你自己的落盘线程才是唯一文件管理者 - 如果必须共存（比如运维强要求），那就把日志写到临时目录（
/tmp/app_log_staging/），落盘线程定期 mv 到正式目录，并通知logrotate只扫正式目录 —— 两边完全解耦 - 所有文件名生成必须带毫秒级时间戳（
std::chrono::system_clock::now().time_since_epoch().count() / 1000000），别依赖strftime，否则同秒内多次滚动会撞名
真正难的不是压缩或滚动，是确保「写缓冲」、「落盘」、「滚动」、「压缩」四个阶段的时间窗口不重叠、句柄不泄漏、错误可退化。少一个原子标志位，多一次裸 close()，就可能丢日志。