[C/C++] C++日志库性能对比与选型指南：从Quill到spdlog的10个高性能方案

还在用 printf 进行调试？在高性能场景下，你的程序可能已经因此付出了巨大的性能代价。对于C++开发者而言，你是否遇到过这些困境：

• 线上系统突然崩溃，但关键日志却因性能瓶颈而来不及落盘？
• 高并发压力下，日志打印操作本身竟成为了系统瓶颈？
• 既需要详细的日志信息用于排查问题，又担心影响核心业务的性能表现？

本文将深入盘点10款业界公认的高性能、低延迟C/C++日志库，从纳秒级延迟到千万级吞吐，结合具体场景为你提供清晰的选型参考。

一、为什么日志性能如此关键？

在高频交易、游戏服务器、实时音视频等对延迟极度敏感的场景中，一次日志调用的耗时可能在几十到几百纳秒之间。如果选用的日志库性能不佳，这些微小延迟累积起来，足以让系统的整体性能大打折扣。

根据最新的性能测试数据，传统的同步日志（例如直接使用 printf）延迟可能高达几微秒甚至毫秒级。相比之下，现代异步日志库已经能够将延迟压缩到8-10纳秒。这个差距有多大？

• 传统同步日志：1000 - 10000 纳秒
• 现代异步日志：8 - 15 纳秒
• 性能提升：100 - 1000 倍！

二、十大高性能日志库全面对比

🥇 第一梯队：纳秒级延迟王者

1. Quill —— 低延迟标杆

GitHub Star: 2.5k+

Quill 在多项测试中展现出最稳定的延迟表现，其95%的日志调用延迟可以稳定在 9-10纳秒。

核心优势：

• 异步非阻塞设计，热路径（hot path）实现零内存分配。
• 基于 fmtlib 提供强大的格式化能力。
• 支持有界队列（bounded queue），有效防止内存无限增长。
• 编译期进行优化，对不同数据类型有特化处理。

适用场景： 金融交易系统、游戏服务器、实时音视频处理等追求极致低延迟的场景。

性能数据：

50th percentile: 8 ns
95th percentile: 9 ns
99.9th percentile: 13 ns
吞吐量: 5.2 M msg/s

示例代码：

#include "quill/Quill.h"

int main()
{
    quill::start();
    auto logger = quill::get_logger();

    LOG_INFO(logger, "Order executed: id={}, price={}, qty={}", 12345, 99.50, 100);

    return 0;
}

---

2. fmtlog —— 极致轻量级选择

GitHub Star: 800+

fmtlog 是一个受 NanoLog 启发而设计的高性能日志库，同样能达到纳秒级的延迟水平。

核心优势：

• 每个线程使用独立的 SPSC（单生产者单消费者）队列，从根本上避免线程竞争。
• 队列满载时可灵活选择丢弃日志或阻塞线程，以应对不同场景。
• Header-only 设计，集成非常简便。
• 基于 fmtlib，使用现代化的格式化语法。

适用场景： 对集成便利性和运行时性能都有较高要求的项目。

性能数据：

50th percentile: 8 ns
95th percentile: 10 ns
吞吐量（非阻塞模式）: 与 Quill 并列第一

特色功能：

• 支持日志回调函数，允许自定义日志处理逻辑。
• 支持日志频率限制，有效避免“日志风暴”。
• 提供编译期和运行期双重日志级别过滤。

---

3. NanoLog —— 学术界的性能标杆

来自斯坦福大学的研究项目

NanoLog 采用了一种革命性的设计思路：通过编译期预处理将格式化等大量工作提前完成，使得运行时开销极低，几乎只剩下内存拷贝操作。

核心优势：

• 延迟最低可达 8 纳秒。
• 吞吐量高达 82 M msg/s（理论测试数据）。
• 输出高度压缩的二进制日志，体积比文本日志小10倍以上。
• 编译期完成字符串处理，运行时开销极小。

⚠️ 需要注意：

• 日志文件为二进制格式，需要使用专用工具进行解析。
• 无法直接使用 tail 等命令实时查看日志内容。
• 设计理念独特，学习曲线相对陡峭。

适用场景： 对性能有极致要求，且可以接受二进制日志格式的高性能计算、底层系统或科研项目。

性能对比： 多个独立测试显示，在保证不丢失日志的模式下，NanoLog 的性能表现堪称绝对王者，即便在高压场景下也能维持极高的吞吐量和稳定的低延迟。

---

🥈 第二梯队：功能与性能的平衡之选

4. spdlog —— 最受欢迎的实用主义者

GitHub Star: 24k+

spdlog 很可能是目前 C++ 社区中最流行、受众最广的日志库，它在性能、易用性和功能丰富度之间取得了良好的平衡，是许多开源实战项目的首选。

核心优势：

• 基于 fmtlib，提供强大且类型安全的格式化功能。
• 支持多种输出目标（sink）：文件、控制台、syslog、Windows事件日志等。
• 支持按文件大小或时间自动进行日志轮转。
• 支持彩色控制台输出，提升可读性。
• 良好的跨平台支持（Windows/Linux/macOS）。
• 提供 Header-only 或编译为静态/动态库两种使用模式。

性能数据：

吞吐量: 4.3 M msg/s
延迟: 在异步模式下可达几十纳秒级别

适用场景： 通用项目的首选，特别适合需要丰富功能、良好文档和社区支持的应用。

示例代码：

#include "spdlog/spdlog.h"
#include "spdlog/sinks/rotating_file_sink.h"

int main()
{
    // 创建每 5MB 轮转一次的日志器
    auto logger = spdlog::rotating_logger_mt("app_logger", "logs/app.log", 1024*1024*5, 3);

    logger->info("Server started on port {}", 8080);
    logger->warn("Connection pool size: {}", 100);

    return 0;
}

---

5. glog —— Google 出品，久经考验

Google 官方维护

glog 是 Google 内部广泛使用的日志库，在 C++ 社区拥有极高的知名度和可靠性口碑。

核心优势：

• 条件日志（LOG_IF）：仅在条件满足时记录日志。
• 按频率记录（LOG_EVERY_N）：避免循环中产生海量日志。
• 集成 CHECK 宏，将断言与日志记录结合。
• 支持按日期自动分割日志文件。
• 能记录详细的程序崩溃信息，便于事后分析。

适用场景： 大型 C++ 项目，特别是对稳定性和可靠性要求极高的企业级应用。

示例代码：

#include <glog/logging.h>

int main(int argc, char* argv[])
{
    google::InitGoogleLogging(argv[0]);

    LOG(INFO) << "Program started";

    // 条件日志
    LOG_IF(WARNING, size > 1000) << "Large data: " << size;

    // 每处理 100 条记录一次日志
    LOG_EVERY_N(INFO, 100) << "Processed " << google::COUNTER << " items";

    return 0;
}

---

6. haclog —— 纯 C 语言的异步日志库

专为 C 语言设计

haclog 是一个较为罕见的纯 C 语言实现的高性能异步日志库。

核心优势：

• 纯 C 实现，无需任何 C++ 运行时依赖。
• 采用异步非阻塞设计。
• 在公开性能测试中表现优异。
• 在模拟真实应用间歇性写入日志的场景中表现尤其出色。

适用场景： 纯 C 语言项目，或对 C++ 依赖有严格限制的嵌入式系统、底层系统编程项目。

---

🥉 第三梯队：特色功能派

7. reckless —— 高吞吐量专家

reckless 的设计目标是追求极致的日志吞吐量，非常适合日志产生量巨大的场景。

核心优势：

• 异步设计，由后台线程负责日志处理。
• 采用无锁（lock-free）数据结构，减少线程竞争。
• 在高吞吐量测试中表现突出。

性能数据：

95th percentile: 32 ns
吞吐量: 2.7 M msg/s

---

8. log4cplus —— Java Log4j 的 C++ 移植版

经典的企业级日志方案

核心优势：

• 采用配置文件驱动，配置灵活，无需重新编译即可改变日志行为。
• 支持分层日志器（Logger Hierarchy），便于按模块管理日志级别。
• 提供丰富的 Appender（输出目标），支持文件、网络、邮件等。
• 功能全面，适合复杂的企业级日志管理需求。

适用场景： 需要复杂日志配置、集中管理和多种输出方式的企业级应用。

---

9. Easylogging++ —— 单头文件的瑞士军刀

曾经非常流行（近期维护较少）

核心优势：

• 单头文件，集成极其轻便。
• 功能异常丰富，包括性能追踪、STL容器直接打印等。
• 配置方式灵活。

⚠️ 注意：

• 最近一年更新较少，GitHub上有大量未解决的 issue。
• 如果项目要求依赖库有活跃的社区维护，建议选择其他方案。

---

10. loguru —— 轻量级的美学派

极简主义设计哲学

核心优势：

• 代码库非常简洁，易于阅读、理解和自行修改。
• 集成了信号处理和程序崩溃报告功能。
• 适合小型项目或原型快速集成日志功能。

---

三、实战选型指南

按场景选择

场景	首选	备选
极致低延迟（如金融交易）	Quill, fmtlog	NanoLog
高吞吐量（如大数据处理）	NanoLog, Quill	haclog
通用项目	spdlog	glog
C 语言项目	haclog	-
企业级应用（需复杂管理）	glog	log4cplus
快速原型	spdlog	loguru

💡 按性能指标选择

延迟敏感（看95分位延迟）：

1. Quill / fmtlog: ~9-10 ns
2. NanoLog: ~18 ns
3. reckless: ~32 ns

吞吐量敏感：

1. NanoLog: 82 M msg/s (理论值)
2. Quill: 5.2 M msg/s
3. spdlog: 4.3 M msg/s

四、性能测试深度解析

根据多个独立的基准测试结果，我们可以得出以下更细致的结论：

场景 1：突发高负载

模拟短时间内密集写入大量日志，测试日志库队列的抗压能力。

• 表现最佳：fmtlog (dropping 模式) 和 Quill (bounded dropping 模式)。它们在队列满载时选择丢弃新日志，以此保证前端线程的极致性能。适用于可以容忍极少量日志丢失的场景。
• 平衡之选：NanoLog。即使在保证不丢失任何日志的模式下，它依然能保持极高的性能，适合对日志完整性有要求，同时追求高性能的场景。

场景 2：持续稳定输出

模拟真实应用程序中间歇性、稳定产生日志的模式。

• 表现最佳：haclog 在此场景下表现尤为出色；NanoLog 继续保持领先地位；Quill 则提供稳定且极低的延迟表现。

🤔 关键权衡点

1. 日志丢失 vs 性能

   • 允许丢失：fmtlog、Quill（dropping模式）能提供最佳性能。
   • 不允许丢失：NanoLog、haclog、Quill（blocking模式）是更可靠的选择。

2. 可读性 vs 性能

   • 二进制日志：NanoLog（性能极致，但需专用工具解析）。
   • 文本日志：Quill、spdlog、fmtlog（人类直接可读，便于调试）。

3. 功能丰富度 vs 简洁性

   • 功能丰富：spdlog、glog、log4cplus。
   • 极简高效：fmtlog、Quill、NanoLog。

五、最佳实践建议

1. 异步设计是高性能的基石

同步日志的I/O操作会直接阻塞调用线程，严重影响性能。对于任何对性能有要求的项目，应优先选择异步日志库。

2. 合理设置日志级别

• 开发环境：可设置为 DEBUG 或 TRACE。
• 生产环境：建议设置为 INFO 或 WARNING。
• 利用编译期过滤：使用支持编译期日志级别过滤的库（如 fmtlog），可以完全消除低级别日志语句的运行时开销。

3. 预分配内存

对于 fmtlog 等库，在线程初始化时主动调用 preallocate() 函数，可以确保首次日志写入也能获得低延迟。

4. 选择合适的后台队列大小

• 队列太小：容易满，导致日志被丢弃或前端线程阻塞。
• 队列太大：浪费内存，且可能因缓存不友好而影响性能。
• 建议：根据实际应用的日志产生量进行测试和调整，通常 1MB 到 8MB 是一个合理的起步范围。

5. 监控日志性能

在生产环境中，应定期检查：

• 日志调用的平均延迟和 P99（99分位）延迟。
• 日志库后台线程的处理速度是否跟得上日志产生速度。
• 是否发生了日志丢弃事件。

6. 避免“日志风暴”

• 使用 LOG_EVERY_N（glog风格）或类似功能限制高频重复日志。
• 对于循环内的日志，考虑改为批量输出或采样输出。
• 善用条件日志（LOG_IF），仅在异常或特定条件下记录。

六、未来趋势

1. 编译期优化日益重要

随着 C++17/20 的 constexpr 能力增强，更多工作（如格式字符串解析、类型检查）可以前置到编译期，从而进一步降低运行时开销。

2. 结构化日志兴起

JSON、MessagePack 等结构化日志格式越来越受欢迎，它们便于与 ELK（Elasticsearch, Logstash, Kibana）等日志分析系统集成，实现更强大的日志查询和聚合分析。

3. 与分布式追踪深度集成

OpenTelemetry 等标准的普及，正推动应用日志与分布式请求追踪（Tracing）的上下文信息进行深度关联，提升全链路排查问题的效率。

4. 异构计算可能介入

在超大规模系统、物联网等日志量极大的场景，未来可能会出现利用 GPU 或专用硬件进行日志压缩、过滤和转发的加速方案。

七、总结

选择日志库就像为项目选择称手的工具，没有绝对的“最优解”，只有“最适合”。

• 追求极致性能：Quill、fmtlog、NanoLog
• 需要功能丰富且稳定：spdlog、glog
• 纯C语言项目：haclog
• 追求快速集成：spdlog（Header-only模式）

请牢记核心原则：

1. 异步优于同步：这是实现高性能日志的架构基础。
2. 测试先于选择：理论数据仅供参考，必须在你的实际业务场景和硬件环境下进行基准测试。
3. 合适重于流行：最流行的不一定最适合你的特定需求（如延迟、吞吐、语言）。
4. 稳定压倒一切：对于线上核心系统，日志库的稳定性和可靠性至关重要。

最后也是最重要的建议：无论你最终倾向于哪个日志库，都请务必在你的实际应用环境中进行基准测试！ 只有真实的数据才能告诉你，谁才是你项目中的“性能之王”。

开源日志库 GitHub 链接

1. Quill: https://github.com/odygrd/quill
2. spdlog: https://github.com/gabime/spdlog
3. fmtlog: https://github.com/MengRao/fmtlog
4. NanoLog: https://github.com/PlatformLab/NanoLog
5. glog: https://github.com/google/glog
6. haclog: https://github.com/MuggleWei/haclog
7. reckless: https://github.com/mattiasflodin/reckless
8. log4cplus: https://github.com/log4cplus/log4cplus
9. Easylogging++: https://github.com/abumq/easyloggingpp
10. loguru: https://github.com/emilk/loguru

希望这份详尽的对比与指南能帮助你在项目中做出更明智的技术选型。如果你有更多关于C++高性能编程的经验或问题，欢迎在云栈社区与广大开发者交流探讨。