微服务日志必须含 trace_id 且为单行 JSON 格式，使用 contextvars 注入 trace_id、python-json-logger 库序列化、ISO8601 UTC 时间戳（timestamp 字段），线上仅保留 levelno。
日志格式必须包含 trace_id 才算可用
微服务或分布式系统里，没有 trace_id 的日志等于丢了一半线索。Python 标准 logging 默认不带上下文透传能力，直接用 %(message)s 或 %(asctime)s 格式输出，查问题时根本串不起一次请求。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
threading.local或contextvars.ContextVar（Python 3.7+）存trace_id，在每次请求入口生成并绑定 - 自定义
logging.Filter，把trace_id注入到LogRecord属性中，再通过%(trace_id)s在格式字符串里引用 - 避免用
extra参数临时传trace_id—— 中间件、异步调用、线程切换后容易丢失
JSON 格式日志不是“更高级”，而是运维刚需
纯文本日志在 ELK、Loki 或云厂商日志服务里解析困难，字段提取靠正则，一改格式就崩。JSON 日志能被直接 ingest、filter、聚合，前提是每条日志是合法单行 JSON。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 别手写
json.dumps()拼接字符串 —— 容易漏转义、字段冲突、非 UTF-8 字符崩溃；用python-json-logger库的JsonFormatter - 确保
exc_info=True时异常栈也被序列化进exc_info字段，而不是混在message里 - 禁用
%(pathname)s和%(funcName)s等含斜杠/括号的字段名 —— JSON 解析器可能报错；改用file_path、func_name这类安全 key
levelno 和 levelname 都要保留，但别同时用
levelno（如 40）适合监控告警做数值比较，levelname（如 “ERROR”）适合人眼快速识别。但日志字段冗余会增大体积、拖慢序列化，尤其高频 INFO 日志。
