C++轻量日志库应以线程安全、高性能、易用可扩展为设计核心，采用enum class日志级别、轻量消息结构、延迟格式化、无锁入队+单线程刷盘、LogSink接口抽象及懒加载单例模式。
用C++写一个实用的日志库，核心不是堆功能，而是平衡线程安全、性能、易用性和可扩展性。从零开始不必追求大而全，先实现“能用、不崩、看得懂”，再逐步加特性。
基础结构：日志级别 + 输出目标
日志库最底层要定义几个关键概念：日志级别（DEBUG/INFO/WARNING/ERROR）、日志消息体（时间、线程ID、模块名、内容）、输出方式（控制台、文件、或两者）。不需要一开始就支持网络或数据库——那些是后期插件化的事。
- 用 enum class 定义级别，配合 constexpr 字符串映射，避免运行时字符串比较
- 日志消息建议封装为轻量结构体（非类），构造时只存必要字段（如 const char* msg, int level, uint64_t timestamp），延迟格式化（避免锁内做 snprintf）
- 输出目标抽象为接口（如 class LogSink），默认提供 ConsoleSink 和 FileSink，便于后续替换或组合
线程安全：别锁整个日志函数
高频打日志时，全局互斥锁是性能杀手。更合理的做法是“无锁入队 + 单线程刷盘”：
- 前端（调用方）用 lock-free queue（如 boost::lockfree::queue 或自己基于原子操作实现的简易环形缓冲区）把日志消息快速入队
- 后台起一个专用日志线程，循环取队列、格式化、写入目标。这样主线程几乎不阻塞
- 如果项目不允许额外线程（如嵌入式），改用 per-thread buffer + 定期 flush，或退化为带细粒度锁的 mutex + 小缓冲区
格式化与上下文：少用 std::string，多用 string_view
格式化是日志开销大头之一。避免在每次 log 调用中构造 std::string 或调用 std::format（C++20）——它们可能触发内存分配。
立即学习“C++免费学习笔记（深入）”；
- 接受 const char* 或 std::string_view 作为消息主体，参数用变参模板（如 template
）延迟展开 - 格式化逻辑尽量放在后台线程里，且优先使用栈上缓冲（如 char buf[512]）+ snprintf；超出再 fallback 到 heap 分配
- 支持简单上下文：比如通过 RAII 类（如 LogScope）自动记录进入/退出，或用宏注入 __FILE__、__LINE__、函数名（__func__）
配置与初始化：静态实例 + 懒加载
日志库应“开箱即用”，但又不能强依赖全局初始化顺序。
- 提供全局函数（如 LOG_INFO("hello")），背后调用单例 Logger::instance()，首次调用时懒初始化（double-checked locking 或 std::call_once）
- 初始化接口简洁：Logger::init(FileSink{"app.log"}, Level::INFO)；支持运行时动态调级（set_level()）和添加 sink（add_sink()）
- 避免静态对象析构期写日志（可能导致 crash），关闭时显式调用 Logger::shutdown()，由用户控制时机
基本上就这些。不复杂但容易忽略的是：日志本身不该成为故障源——它得在内存紧张、线程混乱、甚至部分系统调用失效时仍尽力工作。所以越早做边界检查（如空指针、缓冲区溢出）、越晚做昂贵操作（如堆分配、系统调用），就越稳。
