正确做法是用loggeradapter+contextvars绑定上下文：请求启动时存trace_id到contextvar，loggeradapter.process动态读取并注入extra，避免拼接或初始化固化。
logging 模块怎么透传 trace_id
默认 logging 不知道当前请求有没有 trace，更不会自动把 trace_id 塞进日志。直接在 log message 里拼接是错的——一旦中间件或异步任务切换上下文，trace_id 就会错乱或丢失。
正确做法是用 LoggerAdapter + contextvars（Python 3.7+）绑定当前上下文：
- 启动请求时，从 HTTP header（如
traceparent）或生成新trace_id，存入contextvars.ContextVar - 定义一个
LoggerAdapter子类，在process()方法里读取该ContextVar，注入到extra - 所有日志调用都走这个 adapter 实例，而不是直接用
logging.getLogger()
示例关键行：logger = LoggerAdapter(logging.getLogger(__name__), extra={})，但必须确保 LoggerAdapter.process 里动态读取 trace_var.get()，不能在初始化时固化。
OpenTelemetry 的 logging 自动注入为什么没生效
很多人装了 opentelemetry-instrumentation-logging，发现日志里还是没有 trace_id、span_id。根本原因是：OpenTelemetry 的日志注入只对「当前活跃 span」有效，且仅当 span 处于 active 状态时才写入。
立即学习“Python免费学习笔记（深入）”；
常见失效场景：
- 异步函数（
async def）里没用contextvars透传 context，导致trace.get_current_span()返回None - 日志发生在 span 结束之后（比如在
finally块里打日志，但 span 已被__exit__关闭） - 用了多进程（
multiprocessing），而 OpenTelemetry 默认不跨进程传递 context
验证方法：在打日志前加一行 print(trace.get_current_span())，如果输出 None，说明 span 已断开，得检查 span 生命周期管理位置。
structlog + OpenTelemetry 怎么避免重复字段
structlog 本身支持绑定键值对，和 OpenTelemetry 的日志处理器叠加后，容易把 trace_id、span_id 写两遍——一次来自 structlog 的 bind()，一次来自 OpenTelemetry 的自动注入。
解决方式很直接：
- 禁用 OpenTelemetry 的日志自动注入：初始化时不调用
LoggingInstrumentor().instrument() - 改用
structlog的Processor手动注入，例如写一个add_otel_context函数，内部调用trace.get_current_span()提取字段 - 确保这个 processor 在
structlog.configure()中排在JSONRenderer之前，否则字段进不了最终输出
注意：span.context.trace_id 是整数，需转成十六进制字符串（hex(span.context.trace_id)[2:]），否则日志系统可能报类型错误。
Flask/FastAPI 中 middleware 和 logger 初始化顺序
Web 框架里最容易出问题的是：logger 实例化太早，早于中间件注册，导致请求还没走到 trace 注入逻辑，日志就已经开始写了。
典型错误写法：logger = get_logger() 放在模块顶层；正确做法是延迟到请求生命周期内初始化或绑定：
- FastAPI：用依赖注入，在
Depends函数里获取或构建带上下文的 logger - Flask：在
@app.before_request里设置g.logger，或用app.logger配合自定义LoggerAdapter - 绝不要在
create_app()外部提前调用getLogger()并复用——它没有上下文感知能力
一个信号：如果第一条日志（比如启动日志）里出现了 trace_id，那基本就是初始化时机错了——启动阶段根本没有 trace 上下文。
真正麻烦的不是怎么加字段，而是字段什么时候“有”、什么时候“没”、什么时候“错”。上下文边界比代码缩进还难肉眼识别，尤其在 async/await、threading、multiprocessing 交叉时。
