企业官网建设流程全解析

1. 项目概述与核心价值

做C++项目，尤其是稍微复杂点的服务端应用或者长期运行的后台程序，日志系统绝对是那个平时不显山露水，一出问题就让你恨不得把它供起来的核心组件。我见过太多项目初期图省事，直接std::cout或者printf满天飞，等到线上出问题需要定位时，面对海量、混乱、没有分级、没有上下文的输出，排查起来简直是大海捞针。一个设计良好的日志系统，就像是给程序装上了“黑匣子”和“诊断仪”，它能清晰地记录下程序运行的每一个关键步骤、每一次状态变迁、每一个异常错误，并且能根据不同的环境（开发、测试、生产）和不同的紧急程度（调试、信息、警告、错误）进行灵活的输出和控制。

这个实战项目，就是要从零开始，手把手构建一个轻量级、高性能、功能完备的C++日志库。我们不会去造一个像spdlog或glog那样的巨轮，而是聚焦于理解日志系统的核心原理和设计取舍，实现一个具备实用价值、代码清晰、易于扩展的轮子。通过这个项目，你不仅能掌握文件操作、多线程同步、格式化输出等C++核心技能，更能深刻理解如何在软件架构中设计一个可靠的基础设施组件。无论是为了面试中能侃侃而谈日志系统的设计，还是为了在实际项目中真正解决痛点，这个实战都值得你投入时间。

2. 日志系统核心设计思路拆解

在动手写代码之前，我们必须想清楚一个好的日志系统应该长什么样，需要解决哪些核心问题。盲目开始只会导致代码结构混乱，后期难以维护和扩展。

2.1 核心需求与设计目标

首先，我们得明确我们的日志库需要满足哪些基本要求：

1. 分级输出：这是日志的基石。必须支持常见的日志级别，如DEBUG、INFO、WARN、ERROR、FATAL。不同级别用于不同场景，DEBUG用于开发阶段追踪细节，INFO记录常规流程，WARN标识潜在问题，ERROR和FATAL则用于错误和致命错误。
2. 多输出目的地：日志不能只打印到控制台。必须能同时或选择性地输出到文件、标准输出(stdout/stderr)，甚至未来可以扩展至网络或数据库。文件输出要支持按大小或时间滚动，避免单个日志文件无限膨胀。
3. 高性能与低延迟：日志记录通常是高频操作，尤其是在调试或高并发场景下。它绝不能成为程序的性能瓶颈。这意味着要尽量减少记录日志时的开销，特别是要避免同步I/O操作阻塞业务线程。
4. 线程安全：现代C++程序几乎都是多线程的。日志库必须保证在多线程同时调用日志接口时，不会出现数据竞争、日志行交错混乱等问题。
5. 易用性：接口要简洁直观，最好能像流式操作一样使用，例如LOG(INFO) << "User " << user_id << " logged in from " << ip;。同时，要支持格式化输出（类似printf或C++20的std::format）。
6. 异步日志（可选但强烈推荐）：这是实现高性能的关键。核心思想是将日志的“前端生成”和“后端写入”解耦。业务线程只负责生成日志消息并将其放入一个缓冲区队列，然后立刻返回。由一个或多个专用的后台线程负责从队列中取出消息，执行实际的I/O写入操作（写文件、打印到屏幕等）。

2.2 架构选型：同步 vs. 异步

这是第一个关键决策点。

• 同步日志：每次调用日志接口，都立即、同步地执行格式化、加锁、写入文件等所有操作。优点是实现简单，能保证日志的“实时性”（写入后立刻能在文件里看到）。缺点是每次日志调用都涉及可能很慢的I/O操作，会阻塞调用线程，在高频日志场景下对性能影响巨大。
• 异步日志：如上所述，采用生产者-消费者模型。业务线程是生产者，只生产日志消息到内存缓冲区队列；后台线程是消费者，批量处理队列中的消息进行写入。优点是极大减少了业务线程的等待时间，将I/O延迟的影响降到最低，吞吐量高。缺点是实现复杂，存在“延迟”：日志消息从生成到落盘有一小段延迟（通常在毫秒到秒级，取决于缓冲策略），并且在程序崩溃时，最后几条在缓冲区未来得及写入的日志可能会丢失（需要通过定期刷盘或崩溃信号处理来缓解）。

对于追求性能的实战项目，异步日志架构是我们的不二之选。它用一定的实现复杂度和微小的延迟风险，换来了对业务逻辑近乎零干扰的日志能力，这笔交易非常划算。

2.3 关键技术组件规划

基于异步日志架构，我们可以规划出几个核心模块：

1. 日志前端 (Logger)：提供用户使用的接口宏（如LOG_INFO,LOG_ERROR）和类。负责收集日志信息（级别、时间、文件、行号、消息内容），并生成格式化的日志字符串。
2. 日志消息 (LogMessage)：封装单条日志的所有元数据（时间戳、线程ID、级别、源文件、行号、正文内容等）的结构体或类。
3. 缓冲区 (Buffer)：一块连续的内存区域，用于临时存储格式化后的日志消息。通常采用固定大小的数组，写满后或定时触发时，将其内容交给后端处理。使用缓冲区可以减少内存分配次数和系统调用次数。
4. 缓冲区队列 (BufferQueue)：一个线程安全的队列，用于在前端线程和后端线程之间传递已填满的缓冲区。前端将写满的Buffer放入队列，后端从队列中取出Buffer进行写入。
5. 日志后端 (AsyncLogging)：核心的后台线程逻辑。它循环检查BufferQueue，取出缓冲区，将里面的日志数据写入到最终的目的地（文件、控制台）。同时，它还要管理当前正在写入的缓冲区，以及空闲缓冲区的复用（对象池），以避免频繁的内存申请释放。
6. 输出目的地 (Appender)：负责将日志数据输出到具体的目标。可以设计为基类，然后派生出FileAppender、ConsoleAppender等。这样便于扩展新的输出方式。

3. 核心模块实现与细节解析

接下来，我们深入到代码层面，看看每个模块如何实现，并讨论其中的关键细节和“坑”。

3.1 日志级别与前端接口设计

首先定义日志级别，并用枚举类（enum class）来保证类型安全。

// LogLevel.h #pragma once #include <string> enum class LogLevel : int { DEBUG = 0, INFO, WARN, ERROR, FATAL, LEVEL_COUNT // 用于迭代或数组定义，不是实际级别 }; // 将级别转换为字符串，便于输出 const char* LogLevelToString(LogLevel level); // 将字符串转换为级别，可用于配置 LogLevel LogLevelFromString(const std::string& str);

前端接口的设计目标是易用且高效。我们通常采用宏（Macro）来封装，因为宏可以方便地捕获__FILE__,__LINE__,__func__这些预定义宏，获取调用点的源代码信息。

// Logger.h #pragma once #include “LogLevel.h” #include <memory> #include <string> // 前向声明 class AsyncLogging; class LogMessage; class Logger { public: Logger(const char* file, int line, const char* func, LogLevel level); ~Logger(); // 析构时，将组装好的消息提交到异步日志器 // 获取日志流，用于流式输出 std::ostringstream& stream() { return stream_; } // 初始化全局日志器，设置日志级别、输出文件等 static void Init(LogLevel globalLevel = LogLevel::INFO, const std::string& basename = “default_log”, size_t rollSize = 100 * 1024 * 1024); // 默认100MB滚动 static LogLevel GetGlobalLevel(); static void SetGlobalLevel(LogLevel level); private: LogLevel level_; std::ostringstream stream_; // 用于流式构建日志消息体 const char* file_; // 源文件名 int line_; // 行号 const char* func_; // 函数名 uint64_t time_; // 时间戳（微秒） }; // 核心的日志宏 #define LOG_DEBUG if (Logger::GetGlobalLevel() <= LogLevel::DEBUG) \ Logger(__FILE__, __LINE__, __FUNCTION__, LogLevel::DEBUG).stream() #define LOG_INFO if (Logger::GetGlobalLevel() <= LogLevel::INFO) \ Logger(__FILE__, __LINE__, __FUNCTION__, LogLevel::INFO).stream() // ... 类似定义 LOG_WARN, LOG_ERROR, LOG_FATAL

关键细节解析：

1. if语句的使用：注意宏定义中使用了if语句。if (Logger::GetGlobalLevel() <= LogLevel::DEBUG)会在编译期判断，如果全局日志级别高于DEBUG，则后面的Logger对象根本不会被构造，从而完全消除了这行日志在运行时的所有开销（包括参数压栈、函数调用等）。这是一种重要的性能优化。
2. 流式接口：Logger类内部持有一个std::ostringstream，并在析构函数中将流中的内容最终组装成LogMessage提交。用户可以使用<<操作符自然地拼接各种类型。
3. RAII管理资源：Logger对象在宏展开处创建，在语句结束（分号）时析构。析构函数是提交日志的触发点，确保了日志消息的自动提交，无需手动调用结束函数。

3.2 异步日志后端核心：双缓冲区与队列

这是整个系统最精妙也最复杂的部分。直接用一个std::queue<std::string>加锁，每次日志都push一个字符串，性能会很差，因为涉及频繁的内存分配和锁竞争。

高效的做法是使用“双缓冲区” (Double Buffering)技术，并结合“缓冲区队列”。

工作原理：

1. 前端线程持有一个当前缓冲区 (Current Buffer)。当用户通过LOG_*宏写日志时，数据被追加到这个Current Buffer中。
2. Current Buffer是一个固定大小（比如4MB）的字符数组。当它写满时，或者即使没写满但每隔一个固定时间（比如3秒），前端线程就会将它标记为“已满”，并将其移入一个已满缓冲区队列 (Full Buffer Queue)。
3. 同时，前端线程会立即从空闲缓冲区池 (Spare Buffer Pool)中取出一个新的缓冲区作为Current Buffer，继续供后续日志写入。如果空闲池为空，则分配一个新的缓冲区（这种情况较少）。
4. 后端线程在一个独立循环中运行。它主要做两件事：
   • 定期检查：每隔一个短时间（比如500毫秒），就检查一下Current Buffer是否非空，如果非空，也将其移入Full Buffer Queue。这是为了确保即使日志量不大，日志也能在合理时间内被持久化，避免长时间滞留在内存中。
   • 消费队列：从Full Buffer Queue中取出一个或多个已满的缓冲区，将它们的内容一次性写入文件（通过writev系统调用，可以合并多次写入）。写入完成后，将这些缓冲区清空并放回Spare Buffer Pool，供前端线程复用。

代码结构示意：

// AsyncLogging.h #pragma once #include <atomic> #include <memory> #include <vector> #include <thread> #include “Buffer.h” class AsyncLogging { public: AsyncLogging(const std::string& basename, size_t rollSize, int flushInterval = 3); ~AsyncLogging(); void Append(const char* logline, int len); // 前端调用，添加一条日志行 void Start(); void Stop(); private: void ThreadFunc(); // 后端线程函数 using Buffer = FixedBuffer<kLargeBuffer>; // 例如 4MB 的大缓冲区 using BufferVector = std::vector<std::unique_ptr<Buffer>>; using BufferPtr = BufferVector::value_type; const int flushInterval_; // 刷新间隔（秒） std::atomic<bool> running_; std::string basename_; size_t rollSize_; std::thread thread_; // 前端使用的当前缓冲区 BufferPtr currentBuffer_; BufferPtr nextBuffer_; BufferVector buffersToWrite_; // 后端准备写入的缓冲区集合 // 缓冲区队列，前后端交换数据的地方，需要加锁 std::mutex mutex_; std::condition_variable cond_; BufferVector fullBuffers_; // 已满缓冲区队列 // 空闲缓冲区池通常也由后端线程管理，复用buffersToWrite_写入后的缓冲区 };

为什么是双缓冲区？这里的“双”指的是前端始终持有两个缓冲区：currentBuffer_和nextBuffer_。当currentBuffer_写满被移走时，nextBuffer_立即顶替成为新的currentBuffer_，然后立刻分配或从池中取一个新的作为nextBuffer_。这样做的目的是减少前端线程在临界区（锁内）的等待时间。前端线程在交换缓冲区时，只需要锁住互斥锁很短的时间来移动指针，而不需要等待内存分配（因为nextBuffer_已经预备好了）。

3.3 高性能缓冲区设计

缓冲区是存储日志消息的容器，其设计直接影响性能。我们不使用std::string，因为它的动态增长会带来不可预测的内存分配和拷贝。

// Buffer.h #pragma once #include <algorithm> #include <cstring> #include <string> template<int SIZE> class FixedBuffer { public: FixedBuffer() : cur_(data_) {} ~FixedBuffer() = default; void Append(const char* buf, size_t len) { if (Avail() > len) { memcpy(cur_, buf, len); cur_ += len; } // 否则忽略或处理缓冲区满的情况 } const char* Data() const { return data_; } size_t Length() const { return static_cast<size_t>(cur_ - data_); } size_t Avail() const { return static_cast<size_t>(End() - cur_); } void Reset() { cur_ = data_; } void Bzero() { memset(data_, 0, sizeof(data_)); } // 转换为string，谨慎使用，可能涉及拷贝 std::string ToString() const { return std::string(data_, Length()); } private: const char* End() const { return data_ + sizeof(data_); } char data_[SIZE]; char* cur_; };

关键点：

• 固定大小数组：使用模板参数指定大小，在栈上或作为对象成员分配，内存连续，访问速度快。
• 手动指针管理：用cur_指针指向当前写入位置，Append时直接memcpy，效率极高。
• 零拷贝思想：后端线程写入文件时，直接传递data_指针和Length()，避免了将缓冲区内容拷贝到std::string再写入的额外开销。

3.4 日志文件滚动策略

日志文件不能无限增长。我们需要在文件达到一定大小（如100MB）或时间跨天时，自动创建新的日志文件。

// LogFile.h #pragma once #include <memory> #include <string> class LogFile { public: LogFile(const std::string& basename, size_t rollSize); ~LogFile(); void Append(const char* logline, int len); void Flush(); bool RollFile(); // 滚动文件 private: std::string GetLogFileName(time_t* now); // 根据时间生成带时间戳的文件名 void AppendUnlocked(const char* logline, int len); const std::string basename_; const size_t rollSize_; std::mutex mutex_; std::unique_ptr<FILE, decltype(&fclose)> file_; // 使用RAII管理FILE* time_t startOfPeriod_; // 当前日志文件周期的开始时间（通常是当天0点） time_t lastRoll_; // 上次滚动文件的时间 int count_; // 在同一天内，如果日志量很大，可能需要按序号滚动 };

滚动逻辑：

1. 大小滚动：每次写入前检查当前文件大小，如果超过rollSize_，则触发RollFile()。
2. 时间滚动：在RollFile()或首次写入时，检查当前时间。如果当前时间的“天”数（自Epoch以来的天数）与startOfPeriod_记录的天数不同，说明跨天了，也需要滚动文件。
3. 文件名格式：通常格式为basename_.20241115.153022.log。其中20241115是日期，153022是时间（时分秒），如果同秒内多次滚动，可以加上序号如.log.1。

注意：文件操作要处理好异常。例如，磁盘满、权限不足等情况。我们的实现中，如果文件打开失败，Append操作应该被安全地忽略或回退到标准错误输出，而不是导致程序崩溃。

4. 完整集成与配置使用

将上述模块整合起来，并提供简单的初始化接口。

// 主程序 main.cpp #include “Logger.h” #include <thread> #include <vector> void ThreadFunc(int id) { for (int i = 0; i < 100000; ++i) { LOG_INFO << “Thread “ << id << “: This is log message “ << i; } } int main() { // 1. 初始化日志系统：全局级别为INFO，日志文件前缀为“myapp”，每100MB滚动一次 Logger::Init(LogLevel::INFO, “./logs/myapp”, 100 * 1024 * 1024); LOG_DEBUG << “This debug message will NOT be printed because level is INFO.”; LOG_INFO << “Application started successfully.”; LOG_WARN << “Configuration file not found, using defaults.”; LOG_ERROR << “Failed to connect to database: ” << strerror(errno); // 2. 测试多线程日志 std::vector<std::thread> threads; for (int i = 0; i < 4; ++i) { threads.emplace_back(ThreadFunc, i); } for (auto& t : threads) { t.join(); } LOG_INFO << “All threads finished. Exiting.”; // Logger的清理工作通常在静态对象析构时进行，或可显式调用Shutdown return 0; }

编译与运行： 这是一个纯头文件加源文件的库，只需要C++11或更高标准的编译器。使用CMake管理是个好主意。

# CMakeLists.txt cmake_minimum_required(VERSION 3.10) project(CppLogSystem) set(CMAKE_CXX_STANDARD 11) # 将日志库源文件添加为一个库 add_library(cpplog STATIC src/AsyncLogging.cpp src/LogFile.cpp src/Logger.cpp # ... 其他源文件 ) # 你的主程序 add_executable(main src/main.cpp) target_link_libraries(main cpplog pthread) # 链接日志库和pthread库（用于线程）

5. 性能优化与高级特性探讨

一个基础的异步日志系统完成后，我们可以从以下几个方向思考优化和增强：

5.1 性能瓶颈分析与优化

1. 锁的粒度：前端线程在交换缓冲区时需要加锁（操作fullBuffers_队列）。这个锁的持有时间必须极短，仅用于移动指针或交换容器。我们的双缓冲区设计已经很好地优化了这一点。
2. 内存分配：频繁的new/delete缓冲区是性能杀手。解决方案是使用对象池。后端线程在将缓冲区写入文件后，并不销毁它，而是将其重置后放入一个空闲链表或向量中。前端线程需要新缓冲区时，优先从池中获取。
3. 批量写入：后端线程不应每次只取一个缓冲区写入。可以一次性将fullBuffers_队列中的所有缓冲区取出（通过交换操作，避免逐个弹出），然后使用writev或fwrite批量写入文件。这减少了系统调用次数和磁盘寻址时间。
4. 时间戳获取：每条日志都要获取当前时间。gettimeofday或std::chrono::system_clock::now()可能有一定开销。一个优化点是为每个日志线程缓存一个“当前时间”，该时间由后端线程或一个单独的定时器线程每秒更新一次，并用内存屏障保证可见性。这样，同一秒内的多条日志可以共享同一个时间戳字符串，避免了频繁的系统调用和格式化。这属于比较极致的优化，在日志量极大时才需要考虑。

5.2 扩展输出目的地（Appender模式）

目前我们的后端只写文件。通过引入Appender抽象，可以轻松扩展。

class LogAppender { public: virtual ~LogAppender() = default; virtual void Append(const char* data, size_t length) = 0; virtual void Flush() = 0; }; class FileAppender : public LogAppender { /* 如前所述 */ }; class ConsoleAppender : public LogAppender { public: void Append(const char* data, size_t length) override { fwrite(data, 1, length, stdout); // 或 stderr } void Flush() override { fflush(stdout); } }; // 未来可以扩展：NetworkAppender, UdpAppender, SyslogAppender等 class AsyncLogging { // ... void AddAppender(std::unique_ptr<LogAppender> appender); void RemoveAppender(LogAppender* appender); private: std::vector<std::unique_ptr<LogAppender>> appenders_; };

后端线程的ThreadFunc在拿到缓冲区数据后，遍历appenders_，调用每个Appender的Append方法。

5.3 日志格式化与模式布局

不同的场景可能需要不同的日志格式。例如，开发时希望看到文件名和行号，生产环境可能只关心时间、级别和消息。我们可以设计一个Formatter或Layout类。

class LogFormatter { public: virtual std::string Format(const LogMessage& msg) = 0; }; class PatternFormatter : public LogFormatter { public: explicit PatternFormatter(const std::string& pattern) : pattern_(pattern) {} std::string Format(const LogMessage& msg) override { // 解析pattern_，将 %d{日期}, %p{级别}, %f{文件}, %l{行号}, %m{消息} 等替换为实际值 // 返回格式化后的字符串 } private: std::string pattern_; };

这样，用户可以通过配置字符串“%Y-%m-%d %H:%M:%S [%p] %f:%l - %m%n”来定义自己的日志格式。

5.4 应对程序崩溃的日志可靠性

异步日志的缺点是在程序崩溃（如abort、segmentation fault）时，还在内存缓冲区中的日志会丢失。有几种缓解策略：

1. 定期刷盘 (Flush)：后端线程不仅在有缓冲区时写入，也定期（比如每1秒）将当前前端缓冲区（即使未满）强制刷入队列并写入。这增加了丢失日志的时间窗口。
2. 崩溃信号处理：在程序接收到SIGSEGV,SIGABRT等信号时，在信号处理函数中同步地（注意信号处理函数中只能使用异步信号安全的函数）将当前内存中的所有日志缓冲区写入文件。这能捕获崩溃瞬间的堆栈信息，但实现复杂且危险（在崩溃上下文中分配内存或加锁可能导致死锁）。
3. 内存映射文件：可以考虑使用mmap直接将日志缓冲区映射到文件上。这样日志数据在写入缓冲区的瞬间，操作系统就可能将其同步到磁盘（取决于映射参数）。但这会改变整个缓冲区的设计，复杂度较高。

对于大多数应用，定期刷盘是一个在可靠性和性能之间取得良好平衡的方案。

6. 常见问题排查与实战心得

在实际使用和开发这个日志系统的过程中，你肯定会遇到各种问题。下面是我踩过的一些坑和总结的经验。

6.1 编译与链接问题

• 未定义引用 (undefined reference)：确保所有.cpp文件都正确添加到了编译目标（如CMake的add_library或add_executable）中。特别是模板类的成员函数定义，如果放在.cpp文件里，会导致链接错误，通常需要把实现也放在头文件里。
• 多线程相关函数未找到：如果你使用了std::thread,std::mutex，在链接时需要加上-pthread（GCC/Clang）或指定多线程库。在CMake中，可以用find_package(Threads REQUIRED)和target_link_libraries(your_target Threads::Threads)。
• 静态初始化顺序问题：如果日志系统被设计为全局静态对象，并且在其他全局/静态对象的构造函数中使用，可能会因为静态初始化顺序不确定而导致崩溃。一个常见的模式是使用“局部静态变量”（Meyers‘ Singleton）来获取日志器实例，这能保证在第一次使用时才被初始化。

6.2 运行时问题

• 日志文件没有生成或为空：
  • 检查路径权限：程序是否有在指定目录创建和写入文件的权限？
  • 检查初始化时机：是否在第一次写日志之前调用了Logger::Init()？如果日志宏在全局静态对象中使用，而初始化在main函数里，可能会错过最早的日志。
  • 检查日志级别：是不是全局日志级别设置得过高（如ERROR），导致INFO级别的日志被过滤掉了？
  • 异步日志的延迟：如果是异步日志，记得日志消息从生成到落盘有延迟。程序正常退出时，确保日志后台线程有足够时间刷新所有缓冲区（在AsyncLogging的析构函数中调用Stop和等待线程结束）。
• 日志内容混乱、交错：
  • 线程安全：这是最可能的原因。确保所有共享数据（尤其是缓冲区队列fullBuffers_）的访问都受到互斥锁的保护。检查锁的范围是否正确。
  • 缓冲区溢出：如果单条日志消息的长度超过了前端缓冲区的剩余空间，你的Append函数是如何处理的？简单的截断可能导致格式错误。更健壮的做法是，如果剩余空间不足，直接将当前缓冲区标记为满，换下一个缓冲区，或者对于超长消息，分配一个独立的“超大缓冲区”单独处理。
• 程序退出时卡住或崩溃：
  • 后台线程未正确join：在AsyncLogging的析构函数中，必须设置停止标志，通知后台线程，并等待其结束（thread_.join()）。否则，主线程退出时，后台线程可能还在访问已经被销毁的成员变量。
  • 静态对象析构顺序：如果其他全局对象的析构函数中还在写日志，而日志器本身已经被销毁，就会导致访问违规。可以考虑将日志器设计为“永不销毁”的泄漏模式（对于日志这种基础设施，程序退出时泄漏少量内存是可接受的），或者确保它是最后被销毁的对象之一。

6.3 性能调优心得

• 缓冲区大小：FixedBuffer的大小是个权衡。太小（如1KB）会导致频繁的缓冲区交换和队列操作，增加锁竞争。太大（如10MB）会浪费内存，且在程序崩溃时丢失的日志更多。4MB是一个经过许多项目验证的、比较折中的起始值。
• 刷新间隔：后端线程检查并刷新Current Buffer的间隔（flushInterval_）也影响性能和实时性。间隔太短（如100ms）会增加线程唤醒和检查的开销；间隔太长（如10秒）则日志延迟高，丢失风险大。1到3秒是一个常见的范围。
• 使用性能分析工具：如果怀疑日志系统成为瓶颈，可以用perf、Valgrind的callgrind或简单的时间戳来测量Append函数的耗时，以及锁的竞争情况。优化往往要基于数据，而不是猜测。

6.4 设计模式与代码组织

• 单例模式：全局的AsyncLogging实例通常设计为单例，方便各处访问。但要注意线程安全，推荐使用C++11的magic static（局部静态变量）来实现，既简单又线程安全。
• 避免全局变量：尽管日志器是全局的，但应尽量减少全局可写状态。将配置（如日志级别、文件名）集中管理，并通过接口访问。
• 测试：为日志库编写单元测试是必要的。测试应包括：单线程基本功能、多线程并发写入、日志文件滚动、不同日志级别的过滤、程序正常退出和异常退出时的日志完整性等。多线程测试可以使用Google Test的TEST_P配合不同的线程数参数化进行。

从头实现一个C++日志系统，是一个深入理解系统编程、并发编程和性能优化的绝佳项目。它不像算法题那样炫技，但每一个细节都关乎程序的稳定性和开发效率。当你看到自己写的日志库在百万级并发日志写入下依然稳定运行，日志文件整齐滚动时，那种成就感是实实在在的。这个轮子造好了，会成为你未来所有C++项目中最值得信赖的基石之一。