日志性能优化关键在于级别控制、格式化精简、异步写入和结构化克制：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。
