spdlog异步日志需显式创建并复用全局线程池，使用async_logger时必须提前初始化thread_pool、禁用sink自动刷盘、确保logger/sink/tp生命周期正确，且避免backtrace和低效格式化。
spdlog异步模式必须显式创建线程池
默认的 spdlog::stdout_logger_mt 或 spdlog::basic_logger_mt 都是同步写入，哪怕名字带 mt（multi-threaded）也只表示线程安全，不等于异步。真正异步需用 spdlog::async_logger，且它依赖外部线程池——spdlog 不会自动拉起后台线程。
常见错误是直接 new 一个 async_logger 就以为“异步了”，结果日志卡在队列里不动，因为没配线程池：
auto logger = std::make_shared<:async_logger>("async", sink, spdlog::thread_pool()); // ❌ 空 thread_pool() 不工作</:async_logger>
正确做法是提前创建并复用全局线程池：
-
static auto tp = std::make_shared<:thread_pool>(8192, 2);—— 队列大小 8192，线程数 2（通常 2–4 足够，过多反而增加调度开销） - 所有
async_logger共享该tp，避免每个 logger 自建池导致资源浪费 - 线程池必须在 logger 构造前初始化，否则构造时可能触发未定义行为
文件 sink 要关掉 flush_on 并慎用 daily_file_sink
异步日志下，flush_on(spdlog::level::debug) 这类设置会导致每次 debug 日志都强制刷盘，彻底破坏异步优势；同理，daily_file_sink 在午夜切换文件时会阻塞整个线程池，引发日志堆积甚至丢弃。
实操建议：
- 关闭所有自动 flush：
sink->set_flush_level(spdlog::level::off); - 用
spdlog::sinks::rotating_file_sink_mt替代 daily，按大小轮转更可控，且轮转过程由异步线程执行，不干扰主线程 - 若必须按天切分，改用
spdlog::sinks::daily_file_sink_mt，但要确保rotation_hour和rotation_minute设为业务低峰期，并调大线程池队列容量防溢出
logger 生命周期必须长于线程池和 sinks
典型 crash 场景：局部作用域创建 async_logger，函数返回后 logger 析构，但后台线程还在往已释放的 sink 写数据，触发 use-after-free。
根本原因是 async_logger 析构时仅把 pending 日志推入队列，不等待处理完成；而 sink 若也是局部变量，可能比 logger 更早销毁。
安全做法：
- logger、sink、thread_pool 全部用
static或全局std::shared_ptr管理 - 如需动态生命周期，用
spdlog::drop_all()+spdlog::shutdown()显式清理（注意：后者会阻塞等待所有异步任务完成） - 禁止把 sink 原生指针传给 logger；始终用
std::shared_ptr，让引用计数保活
高吞吐下要注意 backtrace 和格式化开销
开启 spdlog::enable_backtrace(32) 看似方便调试，但在每秒万级日志场景下，backtrace 会显著拖慢异步线程——它需要遍历栈帧并符号化解析，不是零成本操作。
格式化本身也有代价：{:%H:%M:%S.%f} 比 {:%s.%f} 开销大数倍，因前者要查时区、做字符串拼接。
压测验证过的优化点：
- 生产环境禁用
backtrace，问题定位靠 trace_id 关联请求链路 - 时间格式用
{:%s.%f}（Unix 时间戳微秒），避免时区计算 - 避免在 log 语句中拼接字符串，如
logger->info("user {} failed: {}", id, err.to_string());而非"user " + id + " failed: " + err.to_string()—— 后者在 logger 外就分配内存，白耗 CPU
异步日志真正的瓶颈往往不在 I/O，而在格式化和内存分配。队列不溢出、线程不饿死，只是第一步；格式化效率和对象生命周期管理，才是高吞吐下最易被忽略的硬伤。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
