直接在Logger中用extra加TraceID会失效，因为Handler共享且extra值会被复用或覆盖；应使用Filter+threading.local（同步）或contextvars（异步）实现隔离注入，并通过LogRecord工厂统一管理字段。
为什么直接在Logger里加TraceID会失效？
因为 logging 的 Handler 是共享的，而 TraceID 是请求维度的——每次 HTTP 请求（或任务执行）需要独立的 ID。如果在 Logger 实例上用 extra 传一次，后续同 Logger 的所有日志都会复用这个值；更糟的是，在多线程/协程场景下，extra 还可能被其他请求覆盖。
用Filter + threading.local 实现线程隔离的TraceID
核心思路是：把 TraceID 存在 threading.local() 里，再写一个自定义 Filter，在每条日志生成前动态注入字段。这样每个线程看到自己的 TraceID，互不干扰。
实操建议：
- 定义全局
local_ctx = threading.local()，并在请求入口（如 Flask 的before_request或 FastAPI 的依赖）中设置local_ctx.trace_id = "xxx" - 继承
logging.Filter，重写filter(self, record)方法，在里面尝试读取getattr(local_ctx, "trace_id", "-")并赋给record.trace_id - 在 Formatter 中用
%(trace_id)s引用，例如：%(asctime)s %(trace_id)s %(levelname)s %(message)s - 注意：不要在 Filter 里做耗时操作（比如调用 UUID4），否则拖慢所有日志输出
异步环境（asyncio）下必须换 contextvars
threading.local 在 asyncio 中不可靠——协程可能跨线程调度，且 local 不随 await 传递。Python 3.7+ 必须改用 contextvars.ContextVar。
立即学习“Python免费学习笔记（深入）”；
实操建议：
- 声明
trace_id_var = contextvars.ContextVar("trace_id", default="-") - 在异步入口（如 FastAPI 的依赖、aiohttp middleware）中调用
trace_id_var.set("xxx") - Filter 的
filter()方法里改用record.trace_id = trace_id_var.get() - 如果混用同步/异步代码（比如 Celery + FastAPI），得同时支持两种存储方式，判断当前是否在 async context（可用
asyncio.iscoroutinefunction()辅助，但更稳妥的是显式传参或分层设计）
Formatter 里别硬编码字段名，用 LogRecord factory 更灵活
直接在 Formatter 模板里写 %(trace_id)s 看似简单，但一旦要动态增删字段（比如加 span_id、user_id），就得反复改 Formatter 字符串和 Filter 逻辑。更好的做法是统一用 logging.setLogRecordFactory()。
实操建议：
- 定义一个工厂函数，例如：
def custom_record_factory(*args, **kwargs): record = old_factory(*args, **kwargs); record.trace_id = getattr(local_ctx, "trace_id", "-"); return record - 调用
logging.setLogRecordFactory(custom_record_factory)替换默认工厂 - 这样所有 Logger 自动生成的
LogRecord都自带trace_id属性，Formatter 可直接引用，Filter 反而可以去掉 - 缺点：无法按 Handler 差异化注入（比如只对 console handler 加 trace_id），这时还是得回退到 Filter 方案
concurrent.futures.ThreadPoolExecutor，这些地方都需要手动透传 context，否则日志里就只剩 “-”。 
