Flask全局g对象是否存在超时？长时任务中g.usr丢失排查

问题描述 #

我正在用Flask结合Huey处理后台长时间运行任务，Huey消费者（工作进程）启动Flask上下文后执行耗时操作，期间用Flask全局对象g存储用户信息。相关代码如下：

@staticmethod
def CurrentUser():
    if g:
        if hasattr(g, 'usr'):
            user = g.usr
        else:
            # no user is linked to g yet - see if we can find and load one by searching for a UUID in the cookies
            user = UserStateManager.LoadUserState()
            g.usr = user
    else:
        # no g object - maybe we are running outside of the flask context - use a default user
        user = UserStateManager.DefaultUserstate()
    return user

运行约20分钟后，g.usr突然消失了。因为是Huey工作进程执行的代码，IDE调试起来很麻烦（调试上下文不一样）。初始运行一切正常，数据库记录里有userId，但20分钟左右后userId字段就空了，看起来g对象被清理了。想问问g对象里的usr数据消失的触发原因是什么？g对象有没有超时或者垃圾回收机制？

首先得明确：Flask的g对象本来就不是为长时间运行的后台任务设计的，它的生命周期和请求上下文严格绑定，这就是你遇到问题的核心原因。

为什么g.usr会消失？ #

• g的生命周期限制：g是请求上下文的一部分，Flask会在每个HTTP请求开始时创建g，请求结束后立刻销毁并清理它。而Huey的工作进程是长期运行的，不会像HTTP请求那样自动重置上下文——但g实际存储在**线程本地存储（Thread Local Storage, TLS）**里，Huey的工作线程可能会被复用，或者在某些场景下（比如空闲超时、任务异常后重启上下文）导致线程本地的上下文被意外重置。
• Huey的上下文管理漏洞：如果你是在Huey任务里手动初始化Flask上下文，很可能没正确处理上下文的销毁和重建逻辑。有些Huey集成方式会在每个任务开始时创建上下文、结束时销毁，但如果你的任务运行20分钟，中间可能触发Huey的worker空闲检查、内存回收机制，不小心清理了线程本地的上下文数据。
• 垃圾回收的间接影响：虽然g本身没有内置超时，但如果持有g的线程本地存储被标记为垃圾（比如线程被复用但上下文未重新初始化），或者UserStateManager.LoadUserState()返回的对象因循环引用、弱引用被GC回收，也会导致g.usr消失（不过这种情况相对少见）。

怎么解决这个问题？ #

别再用g存储后台任务里的用户信息了，换个更可靠的方案：

• 直接传递用户标识到任务：提交Huey任务时，把用户ID（或必要的唯一标识）作为参数传入，任务里直接用这个ID加载用户信息，完全绕开g。示例：

  # 提交任务时
  huey_task.delay(user_id=current_user.id)
  
  # Huey任务实现
  @huey.task()
  def huey_task(user_id):
      user = UserStateManager.LoadUserStateById(user_id)
      # 后续操作直接使用这个user对象
  

• 手动管理任务级独立上下文：如果一定要用上下文，就在每个Huey任务开头手动创建独立的Flask应用上下文，确保任务结束后销毁它，避免上下文复用冲突。示例：

  from flask import Flask
  
  @huey.task()
  def long_running_task():
      app = create_app()
      with app.app_context():
          # 在这里初始化用户信息，执行耗时操作
          user = UserStateManager.LoadUserState()
          # 用局部变量存储用户，而非g
          # 后续操作使用这个局部user变量
  

• 放弃依赖请求上下文的全局对象：g是为请求级临时存储设计的，后台任务脱离HTTP请求场景，用它本身就不符合设计初衷，换成普通局部变量或自定义的任务上下文存储会更稳定。

内容的提问来源于stack exchange，提问作者Erik Oosterwaal