Python 日志级别在生产环境的合理划分-Python教程-PHP中文网

生产环境默认关闭 DEBUG 级别，因其会泄露敏感信息、增大日志体积；仅排查问题时对特定模块临时启用，并限制输出目标与大小；INFO 表示正常执行，WARNING 表示潜在异常但未失败；ERROR 是否带 traceback 需按定位需求权衡；应使用 dictConfig 实现模块级独立日志配置。

python 日志级别在生产环境的合理划分

生产环境默认关掉 DEBUG，不是因为“它太慢”，而是因为它会暴露内部状态、敏感路径、SQL 原始参数、堆栈细节——这些本不该出现在线上日志里。

常见错误现象：logging.getLogger().setLevel(logging.DEBUG) 被误留在配置中，导致日志体积暴增、磁盘打满、甚至泄露数据库连接串或用户 token。

只在排查特定问题时，临时对某个模块（如 requests 或自定义的 auth_service）单独提级： logging.getLogger('auth_service').setLevel(logging.DEBUG)
确保 DEBUG 日志不进远程日志系统（如 ELK、Sentry），只写本地文件且带轮转和大小限制
用环境变量控制，而非硬编码：os.getenv('LOG_LEVEL', 'INFO')，避免打包后改不了

INFO 是“事情按预期发生了”，WARNING 是“事情没崩，但可能出问题了”——这个分界线最容易模糊，也是线上告警噪音的主要来源。

使用场景举例：

容易踩的坑：WARNING 被当成“轻量 ERROR”，结果监控系统一配 WARNING 告警，每天收 200+ 条，最后没人看。真正该告警的，得是 ERROR 或带特定 tag 的 WARNING（比如加 extra={'alert': True}）。

不一定。捕获异常后记录 ERROR，是否调用 exc_info=True，取决于你是否需要定位到具体哪行代码抛出、上下文变量值是什么。

让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限

下载

性能影响明显：每次 exc_info=True 都会调用 sys.exc_info() 并格式化完整 traceback，比纯字符串慢 3–5 倍（尤其在高频异常场景下）。

框架层全局异常处理器（如 Flask 的 @app.errorhandler(Exception)）建议开 exc_info=True，这是兜底入口
业务逻辑里明确知道异常类型且已处理（如 ValueError 解析失败），只需记录关键字段：logger.error('parse failed for user_id=%s, raw=%r', user_id, raw_data)
用 logger.exception() 替代 logger.error(..., exc_info=True)，语义更清晰，但效果一样

靠根 logger 统一设 level 不够用。微服务里，支付模块要 DEBUG，订单模块只 INFO，必须支持 per-logger 控制。

标准做法是用字典配置 + logging.config.dictConfig()，而不是逐个 setLevel()。

配置里写清楚每个 logger 名称和 level：'loggers': {'payment.core': {'level': 'DEBUG'}, 'order.service': {'level': 'INFO'}}
logger 名称建议跟模块路径一致（如 logging.getLogger(__name__)），方便继承和覆盖
注意 propagate：子 logger 默认把日志往上传给父 logger，如果不想让 payment.core 的 DEBUG 日志再被根 logger 以 INFO 级别重复输出，设 'propagate': False

容易被忽略的一点：Docker 容器里，如果用 basicConfig 初始化过 logger，后续 dictConfig 可能不生效——得先调 logging.getLogger().handlers.clear()。