日志级别应匹配运维与调试需求：开发用DEBUG/INFO，线上默认WARNING，关键错误用ERROR/CRITICAL；需按环境分层设置、明确定义各级语义、避免INFO滥用和敏感信息泄露，并通过过滤器增强实用性。
Python日志级别不是选得越细越好，而是要匹配实际运维和调试需求：开发阶段用 DEBUG 或 INFO，线上环境默认用 WARNING，关键错误必须落到 ERROR 或 CRITICAL，同时确保每个级别有明确的记录意图和后续处理路径。
按环境分层设置级别
不同运行环境对日志的“噪音容忍度”和“问题敏感度”差异很大：
-
本地开发：设为
DEBUG，方便追踪变量、函数调用链、配置加载过程；但建议关闭第三方库的 DEBUG 日志（如 requests、sqlalchemy），避免淹没主线逻辑 -
测试/预发环境：设为
INFO，记录关键流程节点（如“用户登录成功”“订单创建完成”），不输出中间计算细节 -
生产环境：默认设为
WARNING，只记录异常征兆（如重试次数超限、响应延迟过高）；ERROR及以上必须可告警、可定位、可复现
让每个级别承担清晰语义
别把所有打印都塞进 INFO——级别混乱会让日志失去筛选价值。推荐这样定义：
-
DEBUG：仅开发者需要，如“SQL 参数: {'user_id': 123}”、“缓存 key 生成结果: user:123:profile” -
INFO：业务主干流程里程碑，如“支付请求已提交至网关”、“定时任务 job_xxx 开始执行” -
WARNING：非中断性异常，需关注但不立即止损，如“Redis 连接池使用率 92%”、“API 响应耗时 1800ms（阈值 1500ms）” -
ERROR：功能失败且有明确影响，如“微信回调验签失败，订单状态未更新”、“数据库插入违反唯一约束” -
CRITICAL：系统级故障，需立即人工介入，如“配置中心连接断开，降级开关失效”、“核心线程池满载，新请求被拒绝”
避免常见误用陷阱
很多团队的日志“看起来很全”，但查问题时依然抓瞎，往往因为：
立即学习“Python免费学习笔记（深入）”；
- 用
INFO记录本该是ERROR的异常（比如捕获了requests.Timeout却只打 INFO） - 在
DEBUG中硬编码敏感信息（如密码、token），上线后忘记清理，导致泄露风险 - 日志级别随代码分支变化（dev 分支 DEBUG，main 分支 INFO），但没同步调整日志内容粒度，造成生产日志信息不足
- 过度依赖
logger.exception()而不补充上下文（如没写清是哪个用户、哪笔订单、什么参数触发的异常）
用过滤器+处理器强化级别实用性
单靠级别不够，配合过滤器才能让日志真正可用：
- 为 ERROR 级别日志自动附加 trace_id、user_id、request_id，便于全链路排查
- 用自定义 Filter 拦截含 “password”、“token” 的日志消息，统一脱敏后再输出
- 对 WARNING 日志加频率限制（如每分钟同类型最多打 3 条），防止单点抖动刷屏
- 将 CRITICAL 日志单独路由到邮件/企微机器人，ERROR 日志接入 Prometheus + AlertManager 告警
日志级别设计本质是信息分级决策——不是技术配置，而是对“谁在什么场景下需要什么信息”的持续校准。定好规则后，定期 review 日志样本，比写一堆文档更有效。
