HTTP 缓存

HTTP 缓存可以显著提高 Web 应用程序的性能。HTTP 缓存围绕 Cache-Control 响应头，随后是条件请求头（例如 Last-Modified 和 ETag）。Cache-Control 建议私有（例如，浏览器）和公共（例如，代理）缓存如何缓存和重用响应。ETag 头用于进行条件请求，如果内容未更改，可能会产生 304 (NOT_MODIFIED) 响应，而无需正文。ETag 可以被视为 Last-Modified 头的更高级的继承者。

本节描述了在 Web MVC 中可用的与 HTTP 缓存相关的选项。

`CacheControl`

CacheControl 提供了对配置与 Cache-Control 头相关的设置的支持，并在多个地方被接受为参数：

虽然 RFC 7234 描述了 Cache-Control 响应头的所有可能指令， CacheControl 类型采用了面向用例的方法，专注于常见的场景：

// Cache for an hour - "Cache-Control: max-age=3600"
CacheControl ccCacheOneHour = CacheControl.maxAge(1, TimeUnit.HOURS);

// Prevent caching - "Cache-Control: no-store"
CacheControl ccNoStore = CacheControl.noStore();

// Cache for ten days in public and private caches,
// public caches should not transform the response
// "Cache-Control: max-age=864000, public, no-transform"
CacheControl ccCustom = CacheControl.maxAge(10, TimeUnit.DAYS).noTransform().cachePublic();

WebContentGenerator 还接受一个更简单的 cachePeriod 属性（以秒为单位），其工作方式如下：

-1 值不生成 Cache-Control 响应头。
0 值通过使用 'Cache-Control: no-store' 指令防止缓存。
n > 0 值通过使用 'Cache-Control: max-age=n' 指令将给定响应缓存 n 秒。

HTTP 处理器

HTTP 处理器可以添加对 HTTP 缓存的显式支持。我们建议这样做，因为资源的 lastModified 或 ETag 值需要在与条件请求头进行比较之前计算出来。控制器可以向 ResponseEntity 添加 ETag 头和 Cache-Control 设置，如下例所示：

@GetMapping("/book/{id}")
public ResponseEntity<Book> showBook(@PathVariable Long id) {

  Book book = findBook(id);
  String version = book.getVersion();

  return ResponseEntity
          .ok()
          .cacheControl(CacheControl.maxAge(30, TimeUnit.DAYS))
          .eTag(version) // lastModified is also available
          .body(book);
}

// 或者其他方式的处理器
public class MyHttpRequestHandler implements HttpRequestHandler {

  @Nullable
  @Override
  public ResponseEntity<Book> handleRequest(RequestContext request) throws Throwable {
    Book book = findBook(id);
    String version = book.getVersion();

    return ResponseEntity
            .ok()
            .cacheControl(CacheControl.maxAge(30, TimeUnit.DAYS))
            .eTag(version) // lastModified is also available
            .body(book);
  }

}

前面的示例在与条件请求头的比较表明内容未更改时，发送一个带有空正文的 304 (NOT_MODIFIED) 响应。否则，将 ETag 和 Cache-Control 头添加到响应中。

您也可以在控制器中对条件请求头进行检查，如下例所示：

@RequestMapping
public String myHandleMethod(RequestContext request, Model model) {

  long eTag = ... (1)

  if (request.checkNotModified(eTag)) {
    return null; (2)
  }

  model.addAttribute(...); (3)
  return "myViewName";
}

1	特定于应用程序的计算。
2	响应已被设置为 304 (NOT_MODIFIED) — 不再进行进一步处理。
3	继续处理请求。

有三种变体用于检查条件请求与 eTag 值、lastModified 值或两者的对比。对于条件 GET 和 HEAD 请求，您可以将响应设置为 304 (NOT_MODIFIED)。对于条件 POST、PUT 和 DELETE，您可以将响应设置为 412 (PRECONDITION_FAILED)，以防止并发修改。

静态资源

为了获得最佳性能，您应该使用 Cache-Control 和条件响应头提供静态资源。请参阅有关配置静态资源的部分。