【Python】Flask上下文管理

current_app
- 类型：用用上下文的代理对象
- 主要用途：提供对当前激活的Flask应用实例的访问。通常访问应用配置，注册的蓝图，应用级别的数据等等
- 使用场景：在视图函数，错误处理器或者其他任何需要访问应用配置和属性的地方
- 实际数据实例：'current_app.config['DEBUG']'可以获取当前应用的调试模式的状态
'g'
- 类型：应用上选文的全局变量
- 主要用途：在一次请求的生命周期内存储和共享数据。'g'可以被用来保存数据库连接，用户认证信息等跨函数调用的临时数据
- 使用场景：在处理一个请求得分时候，用于在视图函数，模板以及请求钩子之间共享数据
- 实际数据实例：在请求开始时设置'g.user=get_current_user()',然后再后续的视图函数或者模板中使用'g.user'来访问当前用户的信息。
request
- 类型:请求上下文的代理对象
- 主要用途：封装了客户端发起的http请求的所有的数据，包括URL,METHOD等
- 使用场景：再视图函数中处理和响应客户的请求时候，访问请求数据
- 实际数据实例："request.from"
session
- 类型：请求上下文的字典对象
- 主要用途：允许跨请求保持信息。基于客户端的cookie实现，可用于存储用户会话数据，比如登录状态，用户偏好设置等
- 使用场景：再用户登录流程中存储用户身份信息，以及跨页面请求保持用户状态
- 实际数据实例："session['user_id'] = 2"存储再当前登录用户的ID，用户跨请求识别用户
区别和选择场景使用
- 请求独立性：'request'和'session'都是请求范围的，但是''session'可以跨请求保持状态，而request只与当前请求有关。
- 数据共享：'g'用于再处理当个请求的不同阶段共享数据，而'current_app'提供了一个接口来访问和操作应用级别的资源和配置
- 生命周期：'current_app'和'g'属于应用上下文，与应用生命周期想匹配；'request'和'session'属于请求上下文，更短暂，但是'session'数据再客户端持久化，能够跨请求保留
g不是只处理当前请求的一写全局变量的数据吗？为什么会是应用上下文呢？
- g的用途
  - 请求级别的存储：'g'确实时用来在一个请求的生命周期内存储和共享数据，他为当前请求提供了一个临时存储，每次请求开始的时候清空，请求结束的时候销毁，这使得'g'成为了在处理特定请求的不同部分之间共享数据的理想选择
- g和应用上下文
  - 生命周期管理：尽管'g'是按照请求生命周期管理的，他任然是在应用上下文中被创建和销毁的。这是因为flask使用上下文局部对象来让特定的变量在一个线程中全局可以访问，而不会影响到其他的线程。'g'对象就是这样一个上下文局部对象，他依赖于应用上下文的激活来确定其作用范围
  - 技术实现的角度：从技术实现的角度看，'g'对象被设计为随着应用上下文而存在，尽管他的内容和生命周期是按请求来管理的。这意味着，即使'g'用于存储请求级别的数据，他的存在任然依赖于当前的应用上下文
- 问什么这样设计
  - 这种设计允许'g'在单个请求处理过程中全局可访问，而不需要开发者手动传递他，同时将'g'的生命周期绑定到应用上下文有助于在使用多线程模式或多进程模式的时候，保持数据的隔离和线程安全。