Flask 3 中 request_id 需在 before_request 中用 uuid.uuid4() 生成并存入 g，避免视图或 after_request 设置；日志需通过 LoggerAdapter 在 record.extra 中注入，不可在 Formatter 中直接访问 g。
Flask 3 中 request_id 怎么生成和注入到 g 对象
Flask 3 默认不自动提供 request_id，必须手动创建并绑定到 g。常见错误是直接在视图里生成——这会导致中间件、异常处理、日志处理器等环节拿不到一致 ID。
正确做法是在请求生命周期最早可介入点（before_request）生成，并存入 g：
@app.before_request
def set_request_id():
if not hasattr(g, 'request_id'):
g.request_id = str(uuid.uuid4())
- 用
uuid.uuid4()而非time.time()或自增数，避免冲突和可预测性 - 加
hasattr(g, 'request_id')判断，防止被多次覆盖（比如某些测试框架或中间件重复触发before_request） - 不要在
after_request或视图函数里设，否则日志写入时可能已出作用域
如何让所有日志自动带上 g.request_id
Python 标准日志模块本身不感知 Flask 的 g，必须靠 LoggerAdapter 或自定义 Formatter 注入上下文。直接在每条 logger.info() 里手动传 extra={'request_id': g.request_id} 容易遗漏且难维护。
推荐用 LoggerAdapter 封装全局 logger：
立即学习“Python免费学习笔记（深入）”；
class RequestContextAdapter(logging.LoggerAdapter):
def process(self, msg, kwargs):
request_id = getattr(g, 'request_id', 'N/A')
kwargs['extra'] = kwargs.get('extra', {})
kwargs['extra']['request_id'] = request_id
return msg, kwargs
<p>logger = RequestContextAdapter(logging.getLogger(<strong>name</strong>), {})
- 必须在应用上下文内调用
logger.xxx()，否则g不可用，会抛RuntimeError: Working outside of application context - 如果用了
gunicorn多 worker，确保每个请求都进入独立上下文——Flask 3 默认满足，但自定义中间件若提前返回响应，可能跳过before_request - 避免在
app.logger上直接加 adapter，它不继承 formatter 配置；应新建专用 logger 并配置 handler
Flask 3 的 app context 和 request context 对 g 的影响
Flask 3 明确区分了 app context（如 CLI 命令、后台任务）和 request context（HTTP 请求）。g 是 request-scoped 的，**在非请求场景下访问 g.request_id 必然报错**。
- 后台任务（如 Celery）、定时任务、shell 命令中不能依赖
g.request_id，需单独生成并透传 - 异步视图（
async def）中g仍可用，但注意：若在协程中启动新线程，g不会自动继承，需显式传递 - 使用
copy_current_request_context仅适用于同步回调；对 async/await 场景无效，得靠contextvars手动绑定
为什么 logging.Formatter 里不能直接用 g.request_id
因为 Formatter.format() 在日志记录时执行，此时不一定有 active request context。常见错误写法：
class RequestIdFormatter(logging.Formatter):
def format(self, record):
record.request_id = g.request_id # ❌ 运行时报 RuntimeError
return super().format(record)
根本原因是 Formatter 可能在任意线程、任意时间被调用（比如日志轮转、异步写入），而 g 只在当前请求的主线程上下文中存在。
- 唯一安全的方式是：在日志记录发起时（即调用
logger.info()等）把上下文数据塞进extra，由Formatter从record中取 - 如果用了结构化日志（如
structlog），也必须在绑定阶段（bind()）完成request_id注入，而非格式化阶段 - 调试时可在
before_request打印id(g)，确认每次请求的g实例不同，避免误以为它是全局单例
Flask 3 的链路追踪不难做，难的是边界情况——比如异常未被捕获导致 g 来不及设、多线程日志、CLI 命令混用同一 logger 实例。这些地方漏掉，日志就断链了。
