python生产环境日志需结构化、分级合理、json行格式输出、上下文贯穿传播；禁用字符串拼接、thread-local、rotatingfilehandler；info/error等须带trace_id、user_id等关键字段。
Python 生产环境日志不是“能打印就行”，而是要可追溯、可过滤、可聚合、低干扰、不拖慢服务——核心是平衡可观测性与运行开销。
结构化日志：用字典代替字符串拼接
非结构化日志（如 logging.info("User %s logged in at %s" % (user_id, now))）难以被 ELK、Loki 或 Datadog 自动解析。应统一使用结构化字段：
- 用
logger.info("User login", extra={"user_id": user_id, "ip": request_ip, "status": "success"}) - 或更推荐的
structlog：自动注入时间、级别、上下文，并支持 JSON 输出 - 避免在
extra中传复杂对象（如 request 对象），只传基础类型（str/int/bool/dict/list）
分级合理 + 关键字段必带
INFO 不是垃圾桶，ERROR 不该靠 grep 猜原因：
- DEBUG：仅开发/排查时开启，含敏感数据（如 SQL 参数、token 片段），生产默认关闭
- INFO：记录关键业务节点（如“订单创建成功”“支付回调接收”），必须含 trace_id、user_id、service_name
- WARNING：异常但可恢复（如第三方 API 超时重试中），需含 retry_count、upstream
-
ERROR：必须带完整 traceback（用
exc_info=True），且附加 context 字典（如请求 ID、参数摘要、上游响应码）
输出与轮转：JSON 行格式 + 时间切片
别用 FileHandler 直写文本，生产环境优先选：
立即学习“Python免费学习笔记（深入）”；
- 输出为单行 JSON（每行一个合法 JSON 对象），便于日志采集器（Filebeat / Fluentd）解析
- 用
TimedRotatingFileHandler按天切分，保留 7–30 天，避免单文件过大卡住 I/O - 禁用
RotatingFileHandler（按大小轮转易导致日志截断、丢失上下文） - 若用 systemd，直接 stdout/stderr 输出，由 journald 统一收集和索引
上下文传播：从入口贯穿到最深调用
一次请求的日志散落在多个模块？靠手动传 trace_id 易遗漏：
- Web 框架层（Flask/FastAPI）在请求开始时生成
trace_id，存入contextvars.ContextVar - 所有 logger 封装一层
get_logger()，自动注入当前 context 中的 trace_id、user_id、endpoint - 异步任务（Celery/Apscheduler）通过 task headers 或 job args 显式传递 trace_id，并在 worker 中重新绑定 context
- 禁止用 thread-local（asyncio 下失效），必须用
contextvars
不复杂但容易忽略：日志不是写得越多越好，而是每一行都要回答“谁、在哪、做了什么、结果如何、凭什么出问题”。
