Python日志系统设计核心是分级控制、输出分离与上下文可追溯：按DEBUG/INFO/WARNING/ERROR/CRITICAL五级规范使用；通过多Handler实现终端、轮转文件、错误专用文件等分离输出；用命名空间（如"api.auth"）隔离模块；注入request_id、user_id、trace_id确保上下文完整。
Python日志系统设计核心在于分级控制 + 输出分离 + 上下文可追溯，不是简单调用logging.info()就完事。关键要让不同环境、不同模块、不同严重程度的日志各走各的路，查问题时能快速聚焦。
按严重程度分五级，但别滥用DEBUG和NOTSET
Python内置DEBUG、INFO、WARNING、ERROR、CRITICAL五级，实际项目中建议：
- DEBUG：仅开发/测试环境开启，记录函数入参、SQL语句、API响应体等细节；生产环境默认关闭（避免性能损耗和敏感信息泄露）
- INFO：记录关键业务节点，如“用户123登录成功”“订单456创建完成”，生产环境保留，用于行为审计
- WARNING：表示异常但未中断流程，如缓存未命中、第三方API降级返回、配置项使用默认值——需监控但不告警
- ERROR：发生异常且影响当前请求，如数据库连接失败、JSON解析错误——必须记录完整traceback
- CRITICAL：系统级故障，如Redis全部宕机、磁盘写满——立即触发告警，通常伴随服务自检或降级动作
多Handler分离输出：控制台看实时，文件留归档，错误单独捕获
一个Logger可绑定多个Handler，实现“一份日志，多处投递”：
- StreamHandler：开发时输出到终端，格式精简（含颜色），级别设为INFO以上
-
RotatingFileHandler：生产环境写入文件，按大小轮转（如每10MB一个新文件，最多保留5个），路径建议统一放在
logs/目录下 -
TimedRotatingFileHandler：按天切分日志（如
app-2024-06-15.log），适合合规审计场景 -
额外ERROR专用Handler：再加一个只接收ERROR及以上级别的文件Handler，命名为
error.log，运维排查时直奔主题
用Logger命名空间隔离模块，避免全局污染
不要只用logging.getLogger()获取root logger。应按包/模块结构命名：
立即学习“Python免费学习笔记（深入）”；
-
logging.getLogger("api.auth")—— 认证相关日志 -
logging.getLogger("service.payment")—— 支付服务日志 -
logging.getLogger("utils.cache")—— 缓存工具类日志
这样可在配置中对某模块单独调高日志级别（比如临时把api.auth设为DEBUG），不影响其他模块；也方便ELK等系统按logger_name字段聚合分析。
带上上下文：请求ID、用户ID、Trace ID缺一不可
单条日志脱离上下文等于无效信息。推荐在中间件或入口处注入关键字段：
- Web服务中，在请求进入时生成唯一
request_id，通过logging.LoggerAdapter或filters注入到每条日志的extra字典 - 异步任务（如Celery）中，从task参数或上下文提取
user_id、task_id一并透传 - 微服务调用链中，从HTTP Header读取
X-Trace-ID，保持全链路可追踪 - 格式示例：
[req:abc123][user:u789][trace:tx-456] 用户登录验证通过
日志不是记流水账，是给未来某个深夜排查问题的自己写的说明书。设计时想清楚谁看、怎么看、看什么，分级和结构自然就清晰了。
