Python日志是系统可观测性基础，需分级管理与请求ID贯穿追踪；按业务语义设定级别，INFO记录可审计事件，WARNING表降级异常，ERROR带traceback直指根因，CRITICAL仅用于服务不可用；模块用getLogger(__name__)隔离，禁用basicConfig；通过Filter注入request_id实现全链路追踪；优先输出JSON结构化日志，敏感信息须脱敏。
Python日志不是“print的高级版”，而是系统可观测性的基础支撑。关键在两点：一是按需分级，让不同严重程度的消息走不同通道；二是贯穿追踪，让一次请求或任务的日志能串起来查。
日志级别要对齐业务语义，不堆砌DEBUG
INFO以上应反映真实业务进展，DEBUG仅用于开发期临时诊断。生产环境INFO通常只记录“用户登录成
功”“订单创建完成”这类可审计事件；WARNING表示异常但未中断流程，比如库存不足但已降级处理；ERROR必须对应明确失败，如数据库连接超时、第三方API返回5xx；CRITICAL极少用，仅限服务完全不可用（如配置加载失败导致进程退出）。
- 避免在循环里打INFO——改用DEBUG或聚合后上报
- WARNING不要写成“可能出错”，而要说明“重试3次后跳过支付回调校验”
- ERROR日志必须带traceback（用exc_info=True），且错误消息直指根因，不说“操作失败”，说“Redis连接被拒绝（host: cache-srv, port: 6379）”
用Logger实例隔离模块，别直接调root
每个模块用logging.getLogger(__name__)获取独立Logger，这样可通过名称前缀统一控制日志行为。例如app.user.auth和app.order.payment可分别设置级别或输出目标，互不影响。
- 禁止用logging.basicConfig()全局配置——它会覆盖已有Handler
- 在包的__init__.py中配置一次Handler和Formatter，子模块复用即可
- 测试时可临时替换模块Logger的Handler为MemoryHandler，避免污染文件
请求/任务ID贯穿全程，靠filter注入而非手动传参
在Web框架（如Flask/FastAPI）或任务队列（如Celery）入口处生成唯一ID（如request_id或task_id），通过LoggerAdapter或自定义Filter自动注入到每条日志的extra字段中，下游无需重复传参。
- Flask示例：在before_request中设g.request_id = str(uuid4())，再用Filter从g取值
- Formatter中用%(request_id)s占位符，确保所有Handler输出一致
- ID格式建议含时间戳前缀（如20250521-abc123），便于按时间范围快速筛选
结构化日志优先，文本日志留作兜底
用json.dumps()将日志字典序列化输出，字段包括level、timestamp、logger、request_id、event（动作名）、duration_ms（耗时）等。结构化后可直连ELK或Loki做聚合分析。
- 非结构化日志仅用于本地调试，生产环境禁用logging.basicConfig(format="%(message)s")
- 敏感字段（如user_id、token）必须脱敏后再进日志，可用Filter拦截并替换
- 大对象（如HTTP响应体）不直接打日志，改用摘要（len(resp_body) + md5(resp_body[:1024])）
