Python 日志打印对性能的影响

日志性能优化关键在于级别控制、格式化精简、异步写入和结构化克制：WARNING以上级别可使低级日志零成本；禁用%(funcName)s等动态字段；用QueueHandler实现异步；避免extra中传未序列化对象。

日志级别设为 WARNING 以上时，几乎不拖慢程序

python 的 Logging 模块默认采用懒求值设计：当当前 logger 的有效级别高于某条日志的级别（比如 logger 设为 WARNING，却调用 logger.debug(...)），整个日志语句的参数格式化、堆栈捕获、处理器分发等操作都会被跳过。这意味着 logger.debug("user_id={}".format(user_id)) 这类调用在 DEBUG 级别未启用时，连字符串拼接都不会执行。

常见错误是误以为“只要写了 logger.debug 就有开销”，其实只要日志级别关得够高，这部分代码就是零成本的条件判断。

• 确认生效级别：用 logger.getEffectiveLevel() 查看实际值，注意父 logger 和 root logger 的继承关系
• 避免手动拼接再传入：写成 logger.debug("user_id=%s", user_id) 而非 logger.debug("user_id=" + str(user_id))，前者只在真正输出时才转换
• 对高频路径（如每毫秒调用一次的函数），即使 INFO 级别开启，也建议用 if logger.isEnabledFor(logging.INFO) 提前拦截

%(asctime)s 和 %(funcName)s 是性能黑洞

格式化字符串中含 %(asctime)s、%(funcName)s、%(lineno)d、%(pathname)s 等动态字段时，每次日志输出都需实时获取调用栈、格式化时间、解析文件路径——这些操作无法缓存，且随日志量线性增长。

尤其 %(funcName)s 和 %(lineno)d 在 CPython 中依赖 inspect.currentframe()，实测在循环中打 10 万条带这两个字段的日志，比不带慢 3–5 倍。

立即学习“Python免费学习笔记（深入）”；

• 生产环境禁用 %(funcName)s 和 %(lineno)d；调试阶段可临时启用，但不要长期开着
• %(asctime)s 若必须，改用 %(created)f（unix 时间戳浮点数），避免 time.strftime 的锁和格式化开销
• 自定义 Formatter 时，重写 format() 方法并缓存 time.time() 结果，可进一步压降 10%–20% 时间

Handler 写文件时的阻塞与缓冲策略

默认的 FileHandler 是同步阻塞的：每次 logger.info() 都会触发一次 write() 系统调用，频繁小写入极易卡住主线程。而 RotatingFileHandler 在检查 rollover 条件时还会加锁并读取文件大小，进一步放大延迟。

这不是 logging 模块的问题，而是 I/O 本身特性。解决方案不是换库，而是控制写入节奏和方式。

• 用 BufferingHandler 或自行包装一个内存 buffer（例如累积 100 条或满 64KB 再刷盘）
• 改用 TimedRotatingFileHandler 替代 RotatingFileHandler，避免每次写都检查文件大小
• 关键服务中，把日志 handler 改为异步：用 QueueHandler + 单独线程消费 QueueListener，主线程几乎无感知
• 切忌在 Handler.emit() 中做耗时操作（如发 http、查 DB），这会让所有日志调用变慢

jsON 日志和结构化字段带来的隐性成本

用 json.dumps() 把 extra 字典序列化进日志消息，看似干净，但每次调用都触发一次完整 JSON 编码——尤其当 extra 含 datetime、bytes、嵌套对象时，编码可能失败或极慢。更隐蔽的是，很多 JSON formatter 会无差别递归遍历所有字段，包括你不关心的 __dict__ 或循环引用。

结构化日志的价值在检索和分析，不在“看起来整齐”。过度结构化反而让单条日志延迟从微秒级升到毫秒级。

• 避免在 extra 中传入未序列化的对象（如 request 对象、model 实例）；先抽关键字段，转成 dict 或 str
• 不用第三方 JSON formatter 库（如 python-json-logger）默认配置；禁用 ensure_ascii=False 和 sort_keys=True，它们显著拖慢编码
• 若需字段索引能力，优先考虑日志采集端（如 Filebeat、Fluentd）做解析，而非在应用层硬塞 JSON

日志性能问题往往不出在“要不要打”，而出在“怎么打”和“打完怎么运”。最常被忽略的是：handler 的实现细节比 logger 配置影响更大，而格式化模板里的一个 s 字符（%(funcName)s）可能比整个业务逻辑还吃 CPU。