std::ofstream不能直接交后台线程落盘，因其write()/flush()同步阻塞，磁盘忙时线程仍卡在syscall；必须用内存缓冲+独立消费者线程+安全队列解耦生成与落盘，否则只是转移卡顿而非真正异步。
为什么 std::ofstream 不能直接交给后台线程做日志落盘
因为 std::ofstream::write() 和 std::ofstream::flush() 是同步阻塞调用，哪怕后台线程在跑，一旦磁盘忙（SSD 延迟突增、ext4 journal 模式卡顿、文件系统缓存压力大），该线程就会停在 syscall 上——你没解耦 IO，只是把卡顿从主线程搬到了后台线程。
真正要隔离的是「日志生成」和「落盘动作」，中间必须有内存缓冲 + 独立线程 + 安全队列。否则所谓“异步”只是自欺欺人。
-
std::ofstream实例不能跨线程共享：它内部streambuf非线程安全，加锁也救不了 - 别在消费者线程里反复
open()/close()日志文件：句柄开销大，且滚动时易丢数据 - 禁用
std::endl：它隐式触发flush()，等同于主动给自己加阻塞点
后台线程怎么写才不丢日志、不卡死、能优雅退出
关键不是“启动一个 thread”，而是让这个线程在进程退出前，把队列清空、刷盘完成、文件 close 干净。漏掉任意一环，最后几条日志就永远留在内存里。
- 用
std::atomic<bool> shutdown_requested{false}</bool>作为全局退出信号 - 消费者循环里不用
cond_.wait(lock)死等，改用cond_.wait_for(lock, 100ms, [&]{ return shutdown_requested || !queue.empty(); }) - 主线程退出前：设
shutdown_requested = true→cond_.notify_one()→thread_.join() -
join()前必须确保消费者已执行完最后一次fflush()或fsync()，否则join()只是等线程结束，不是等日志落盘
FILE* + setvbuf 比 std::ofstream 落盘更稳的实操要点
日志本质是字节流追加写，std::ofstream 的 locale、imbue、sync_with_stdio 等机制在线上环境容易引入不可控开销；而 FILE* 更贴近底层，可控性更强。
- 打开文件用
fopen(path, "a")，立刻调用setvbuf(file_, nullptr, _IOFBF, 64*1024)设 64KB 全缓冲 - 每次写一条日志：先
fwrite(log.c_str(), 1, log.size(), file_)，再fwrite("\n", 1, 1, file_) - 不要每条都
fflush()：只在shutdown时或累计写入 ≥1MB 后主动fflush() - 关键错误需强持久化？慎用
fsync(fileno(file_))—— 它会阻塞，只在极少数场景（如支付失败）触发
缓冲区与队列选型：为什么 moodycamel::ConcurrentQueue 比 std::queue+mutex 更适合高吞吐
不是“锁慢”，而是“锁竞争 + 缓冲区拷贝”双重拖累。业务线程每 push 一次 std::string，就触发一次堆分配和深拷贝；后台线程 pop 后还要再 move 一次——这些开销在百万级 QPS 下直接吃掉 CPU。
- 用
moodycamel::ConcurrentQueue<logentry></logentry>，其中LogEntry是定长结构体（如uint64_t ts; uint8_t level; char msg[1024];） - 格式化必须在生产者线程完成：调用
LOG_INFO("user {} login", uid)时就展开成完整字符串填进msg，避免参数生命周期问题 - 预分配对象池管理
LogEntry*：malloc 一大块内存，按 1024 字节对齐切片，落盘后归还，彻底规避 new/delete - 避免
boost::lockfree::queue：其bounded_queue满时抛异常，日志场景更需要静默丢弃或背压提示
最常被忽略的复杂点是日志滚动与压缩的原子性：rename() 看似原子，但若子进程 gzip 还没读完原文件你就 close() 了句柄，就会出现 read(): Bad file descriptor。这要求滚动逻辑必须和落盘线程强绑定，不能拆到其他线程里去判断文件大小或触发 rename。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
