应用情境¶

这与 请求情境 类似，它在请求期间跟踪请求级数据。推送请求情境时会推送相应的应用情境。

应用对象具有诸如 config 之类的属性，这些属性对于在视图和 中访问很有用。但是，在项目中的模块内导入 app 实例容易导致循环导入问题。当使用应用程序工厂方案 或编写可重用的 或 extensions 时，根本不会有应用程序实例导入。

Flask 通过 应用情境 解决了这个问题。不是直接引用一个 app ，而是使用

代理，该代理指向处理当前活动的应用。

运行使用 .cli.command() 注册到 Flask.cli 的 CLI 命令时，Flask 还会自动推送应用情境。

应用情境根据需要创建和销毁。当 Flask 应用开始处理请求时，它会推送应用情境和 。当请求结束时，它会在请求情境中弹出，然后在应用情境中弹出。通常，应用情境将具有与请求相同的生命周期。

如果您尝试在应用情境之外访问 current_app ，或其他任何使用它的东西，则会看到以下错误消息：

如果在配置应用时发现错误（例如初始化扩展时），那么可以手动推送上下文。因为你可以直接访问 。在 with 块中使用 ，块中运行的所有内容都可以访问 current_app 。:

如果您在代码中的其他地方看到与配置应用无关的错误，则很可能表明应该将该代码移到视图函数或 CLI 命令中。

应用情境是在请求或 CLI 命令期间存储公共数据的好地方。Flask 为此提供了 。它是一个简单的命名空间对象，与应用情境具有相同的生命周期。

Note

g 表示“全局”的意思，但是指的是数据在 情境 之中是全局的。 g中的数据在情境结束后丢失，因此它不是在请求之间存储数据的恰当位置。使用session 或数据库跨请求存储数据。

• teardown_X() 关闭或以其他方式解除分配资源（如果存在）。它被注册为 处理器。
  例如，您可以使用以下方案管理数据库连接:

在一个请求中，每次调用 get_db() 会返回同一个连接，并且会在请求结束时自动关闭连接。

你可以使用 LocalProxy 基于 生成一个新的本地情境:

访问 db 就会内部调用 get_db ，与 的工作方式相同。

如果你正在编写扩展， g 应该保留给用户。你可以将内部数据存储在情境本身中，但一定要使用足够唯一的名称。当前上下文使用 访问。 欲了解更多信息，请参阅Flask 扩展开发 。

当应用情境被弹出时，应用将调用使用 注册的函数。

如果 signals_available 为真，则发送以下信号： 、 appcontext_tearing_down 和 。