log4cpp不适合高性能日志场景，因其同步写入、字符串流拼接耦合格式化与IO、RollingFileAppender依赖慢速复制滚动。

log4cpp 为什么不适合高性能日志场景

log4cpp 是 C++ 早期较流行的日志库，但它的设计基于同步写入 + 字符串流拼接（std::ostringstream），在高并发或高频打点时会成为瓶颈。典型表现是：log4cpp::Category::debug() 调用耗时陡增、线程频繁阻塞在 std::mutex::lock()、日志文件写满后卡顿甚至丢日志。

根本原因有三：一是日志格式化与写入耦合（每次调用都做字符串构造）；二是默认使用 log4cpp::FileAppender 同步刷盘；三是滚动策略依赖 log4cpp::RollingFileAppender 的单次重命名+复制，大文件滚动极慢。

用 async_logger 替代 log4cpp 的核心改造点

现代高性能方案（如 spdlog）采用「异步队列 + 独立日志线程 + 零拷贝格式化」模型。若必须沿用 log4cpp 接口风格，可封装一层异步缓冲层，但更推荐直接切换：

• 替换头文件：#include → #include
• 初始化改为无锁异步模式：

  auto logger = spdlog::rotating_logger_mt("app", "logs/app.log", 1024 * 1024 * 10, 5);

  （10MB 单文件，最多保留 5 个历史文件）
• 关键差异：spdlog 的 spdlog::rotating_logger_mt 内部使用 spdlog::sinks::rotating_file_sink_mt，滚动时仅 rename（不 copy），且支持 set_pattern 延迟格式化
• 避免踩坑：不要用 spdlog::daily_logger_mt 在凌晨秒级并发时触发多线程竞争 rename；改用 rotating_logger_mt + 定期外部清理

手动实现轻量级滚动日志（无第三方依赖）

若项目禁止引入新库，可基于 std::ofstream + stat() 自建滚动逻辑，重点控制三个动作的原子性：

• 判断是否滚动：用 std::filesystem::file_size() 检查当前文件大小，而非依赖写入计数（可能因 crash 不准）
• 滚动操作必须是原子 rename：std::filesystem::rename("app.log", "app.log.1")，而非先 copy 再 delete（大文件卡死）
• 打开新文件前，确保旧句柄已 close：log_stream.close(); log_stream.open("app.log", std::ios::out | std::ios::app);

示例关键片段（省略线程安全包装）：

void rotate_if_needed() {
    const size_t MAX_SIZE = 10 * 1024 * 1024;
    if (std::filesystem::file_size("app.log") > MAX_SIZE) {
        std::filesystem::rename("app.log", "app.log.1");
        log_stream.close();
        log_stream.open("app.log", std::ios::out | std::ios::app);
    }
}

log4cpp 配置文件中滚动参数的真实含义

log4cpp 的 log4cpp.properties 中常见配置：

log4cpp.appender.File=FileAppender
log4cpp.appender.File.fileName=app.log
log4cpp.appender.File.maxFileSize=10485760
log4cpp.appender.File.maxBackupIndex=5

• 错误写法：log4cpp.appender.File=FileAppender → maxFileSize 无效
• 正确写法：log4cpp.appender.File=RollingFileAppender，且需确保链接了 liblog4cpp 的完整版（部分精简包剔除了 Rolling 支持）
• 隐患点：log4cpp 的 maxBackupIndex=5 实际会生成 app.log.1 到 app.log.5，但删除旧文件逻辑在析构时执行，进程非正常退出会导致备份文件堆积

滚动性能差的根源在于：它对每个备份文件执行 std::copy()，100MB 日志滚动一次可能耗时 800ms 以上。