python 3.12 的 f-string 虽更快，但日志格式化不直接受益；logging 默认不用 f-string，且直接在 logger 调用中使用会提前求值，导致无效计算，应优先采用惰性求值的 % 格式化或自定义适配器。
Python 3.12 的 f-string 确实更快，但日志格式化不直接受益
Python 3.12 对 f-string 的编译期优化（比如常量折叠、避免重复查找）确实提升了纯字符串拼接性能，但 logging 模块默认不走 f-string 路径——它用的是 % 格式化或 str.format()，除非你显式写成 f"..."。这意味着：直接在 logger.info(f"User {user.id} logged in") 里用 f-string，看似省事，实际可能拖慢日志——因为字符串在日志级别被过滤掉时，f-string 仍会提前执行。
避免在日志调用中直接使用 f-string
这是最常踩的坑：f-string 在函数调用前就求值，不管日志是否最终输出。比如 DEBUG 级别日志被禁用时，f"Expensive: {heavy_func()}" 依然会执行 heavy_func()，白白浪费 CPU。
- ❌ 错误写法：
logger.debug(f"Result: {compute_slow_value()}") - ✅ 推荐写法：
logger.debug("Result: %s", compute_slow_value())—— 这里compute_slow_value()只在 DEBUG 启用时才调用 - ✅ 或者用
logger.debug("Result: %s", lambda: compute_slow_value())+ 自定义适配器（需额外封装） - 注意：
logging的%格式化在 Python 3.12 下没变快，但它的惰性求值机制仍是优势
想用 f-string 加速？只在确定日志必输出时手动触发
如果你明确知道某条日志一定会记录（比如 ERROR 级别且未被过滤），且变量计算轻量，f-string 才有实际收益。但要确认两点：日志级别未被屏蔽、插值对象无副作用。
- 适用场景：错误兜底日志、启动/关闭等关键生命周期日志
- 示例：
logger.error(f"Failed to write {path}: {e!r}")——path和e已存在，无计算开销 - ⚠️ 避免：
f"{obj.serialize()}"，序列化可能很重；也避免f"{datetime.now()}"，应改用%(asctime)s让 logging 自动注入 - 性能对比（微基准）：对简单变量插值，Python 3.12 的 f-string 比
%快约 15–20%，但这个差距远小于一次意外的提前求值代价
真正提升日志性能的关键不在字符串格式化
日志慢的主因通常是 I/O（写磁盘、网络）、格式器（Formatter 中的 formatTime）、或 handler 同步阻塞。f-string 的提速在这里几乎不可测。
- 优先检查：
RotatingFileHandler是否启用了delay=True；QueueHandler+QueueListener是否部署 - 避免在
Formatter.format()里做任何耗时操作（如调用os.getpid()或查字典） - 如果真要用新特性，Python 3.12 的
logging.setLogRecordFactory()配合自定义LogRecord子类，比折腾 f-string 更可控
复杂点在于：日志性能是系统级问题，不是单个字符串怎么写的局部问题。越早把 f-string 当“银弹”，越容易忽略 handler 队列积压或 JSON 序列化瓶颈这类真实瓶颈。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
