闪存属性为一个请求提供了一种方法，以存储打算在另一个请求中使用的属性。这是在重定向时最常见的需要 - 例如，后重定向-获取模式。Flash 属性在重定向前被暂时保存（通常在会话中），以便在重定向后提供给请求使用，并立即被删除。

    Spring MVC 在支持 Flash 属性方面有两个主要的抽象。FlashMap 用于保存 Flash 属性，而 FlashMapManager 用于存储、检索和管理 FlashMap 实例。

    对 Flash 属性的支持总是 「开启」的，不需要明确地启用。然而，如果不使用，它永远不会导致 HTTP 会话的创建。在每个请求中，都有一个 「input」FlashMap，其中包含从先前请求中传递的属性（如果有的话），还有一个 「output」FlashMap，其中包含为后续请求保存的属性。这两个 FlashMap 实例都可以通过 RequestContextUtils 的静态方法从 Spring MVC 的任何地方访问。

    注解的控制器通常不需要直接与 FlashMap 一起工作。相反，@RequestMapping 方法可以接受一个 RedirectAttributes 类型的参数，并使用它来为重定向场景添加 Flash 属性。通过 RedirectAttributes 添加的 Flash 属性会自动传播到 「out」 的 FlashMap 中。同样地，在重定向后，「input」FlashMap 的属性会自动添加到为目标 URL 服务的控制器的模型中。

    :::info 将请求与 Flash 属性相匹配

    闪存属性的概念存在于许多其他的 Web 框架中，并被证明有时会暴露在并发性问题中。这是因为，根据定义，flash 属性将被存储到下一个请求中。然而，「下一个」请求可能不是预期的接收者，而是另一个异步请求（例如，轮询或资源请求），在这种情况下，flash 属性被过早删除。

    为了减少此类问题发生的可能性，RedirectView 自动用目标重定向 URL 的路径和查询参数 「标记 stamps」FlashMap 实例。反过来，默认的FlashMapManager 在查找 「input」FlashMap 时，会将该信息与传入的请求相匹配。

    这并不能完全消除并发问题的可能性，但利用重定向 URL 中已经存在的信息，可以大大减少并发问题。因此，我们建议你主要在重定向情况下使用 Flash 属性。 :::

    :::tips 该产物，上面说了，多多少少会存在一些问题，然而在分布式环境中更加的用不上这个 :::