Python日志分级管理需围绕场景设计层级、渠道与结构：明确DEBUG到CRITICAL五级语义边界，按环境动态切换级别与输出目标，采用结构化日志注入request_id等字段，ERROR日志须附带可行动线索，并建立分析追踪闭环。
Python日志分级管理不是简单调用logging.debug()或logging.error()，而是围绕“谁在什么场景下需要看到什么信息”来设计层级、输出渠道和内容结构。核心在于让开发查问题时快速定位，让运维监控时及时感知异常，让审计人员能追溯关键操作。
明确五级日志的语义边界
Python内置DEBUG、INFO、WARNING、ERROR、CRITICAL五级，但团队常混淆使用。关键不是“多高”，而是“表达什么”：
- DEBUG：仅限本地调试，如变量值、函数入参/返回、循环内部状态；生产环境默认关闭
- INFO：记录主流程关键节点，如“用户登录成功”“订单创建完成”，不带敏感数据
- WARNING：非中断性异常，如配置缺失、接口降级、重试第2次；提示“可能有问题，但还能跑”
- ERROR：功能失败且无法自动恢复，如数据库连接超时、JSON解析失败；必须人工介入
- CRITICAL：系统级崩溃风险，如磁盘满、内存泄漏告警、认证服务不可用；需立即响应
按环境动态切换日志级别与输出目标
同一份代码，在开发、测试、生产环境应有不同日志行为：
- 开发环境：默认
level=logging.DEBUG，输出到控制台，格式含行号、函数名（%(lineno)d %(funcName)s） - 测试环境：
level=logging.INFO，同时输出到控制台和文件，便于复现流水线问题 - 生产环境：
level=logging.WARNING，仅写入文件（如/var/log/myapp/app.log），禁用控制台输出；错误日志额外路由到RotatingFileHandler并压缩归档
推荐用os.getenv("ENV")或配置文件驱动切换，避免硬编码。
立即学习“Python免费学习笔记（深入）”；
结构化日志提升可追踪性
纯文本日志难检索、难聚合。加入结构化字段，让每条日志自带上下文：
- 必加字段：
request_id（关联一次请求全链路）、user_id（脱敏后）、module（模块名）、action（如"pay_submit"） - 用
LoggerAdapter注入公共上下文，避免每个logger.info()都手动拼接 - 敏感字段如密码、token、身份证号，必须在日志写入前过滤（可用
Filter子类实现正则替换）
示例格式：{"time":"2024-06-15T10:23:41","level":"INFO","request_id":"req_abc123","user_id":"u_88xx","action":"order_create","status":"success","cost_ms":142}
错误日志必须附带可行动线索
ERROR级别不是只写“出错了”，而要回答三个问题：哪里错？为什么错？怎么查？
- 捕获异常时，用
logger.error("DB insert failed", exc_info=True)，自动带完整traceback - 补充业务上下文：
logger.error("Failed to charge user %s for order %s, balance=%s", user_id, order_id, balance) - 对网络类错误，记录下游地址、HTTP状态码、超时时间；对数据库错误，记录SQL片段（参数化后）和影响行数
避免模糊表述如“系统异常”“未知错误”，也不要把多个错误合并成一条日志。
日志分析与追踪闭环建议
日志写了不看等于没写。建立轻量闭环：
- 用
grep -r "ERROR\|CRITICAL" /var/log/myapp/ --include="*.log"每日巡检 - 关键路径（如支付、登录）埋点
INFO日志，配合request_id用awk或jq快速提取单次请求全链路 - 将
WARNING及以上日志接入ELK或Loki，设置关键词告警（如"ConnectionRefusedError"、"TimeoutError"）
不复杂但容易忽略。
