django.views.decorators.cache.cache_page(timeout, *, cache=None, key_prefix=None)

使用缓存框架的通用办法是缓存视图结果。​django.views.decorators.cache​ 定义了一个 ​cache_page ​装饰器，它将自动缓存视图的响应：

from django.views.decorators.cache import cache_page

@cache_page(60 * 15)
def my_view(request):
    ...

​cache_page ​使用了一个单独的参数：缓存过期时间，以秒为单位。在上面的例子里，​my_view()​ 视图的结果将缓存15分钟。（注意，我们用 60 * 15 这样的方式编写，目的是方便阅读。 60 * 15 将计算为 900，也就是15分钟乘以每分钟60秒。）
​cache_page ​设置的缓存超时优先于 ​Cache-Control ​头中的 ​max-age​指令。
和缓存站点一样，对视图缓存，以 URL 为键。如果许多 URL 指向相同的视图，每个 URL 将被单独缓存。继续以 ​my_view ​为例，如果你的 ​URLconf ​是这样的：

urlpatterns = [
    path('foo/<int:code>/', my_view),
]

那么 ​/foo/1/​ 和 ​/foo/23/​ 的请求将被分别缓存，正如你所料。但一旦部分 URL （比如 ​/foo/23/​ ）已经被请求，那么随后的请求都将使用缓存。
​cache_page ​也可以传递可选关键字参数 ​cache​，它指引装饰器在缓存视图结果时使用特定的缓存（来自 ​CACHES ​设置）。默认情况下，将使用默认缓存，但你可以指定任何你想要的缓存：

@cache_page(60 * 15, cache="special_cache")
def my_view(request):
    ...

你可以基于每个视图覆盖缓存前缀。​cache_page ​传递了一个可选关键字参数 ​key_prefix ​，它的工作方式与中间件的 ​CACHE_MIDDLEWARE_KEY_PREFIX ​相同。可以这样使用它：

@cache_page(60 * 15, key_prefix="site1")
def my_view(request):
    ...

​key_prefix ​和 ​cache ​参数可能需要被一起指定。​key_prefix ​参数和 ​CACHES ​下指定的 ​KEY_PREFIX ​将被连接起来。
此外， ​cache_page ​在响应中自动设置 ​Cache-Control​ 和 ​Expires ​头， 这会影响 下游缓存.

在 URLconf 中指定视图缓存

上一节的例子硬编码了视图被缓存的事实，因为 ​cache_page ​改变了 ​my_view ​函数。这种方法将你的视图和缓存系统耦合起来，这样并不理想。例如，你可能想在其他没有缓存的站点上重用这个视图函数，或者你可能想分发这个视图给那些想使用视图但不想缓存它们的人员。解决这些问题的办法是在 ​URLconf ​中指定视图缓存，而不是视图函数旁边指定。
当你在 ​URLconf ​中使用 ​cache_page ​时，可以这样包装视图函数。这是之前提到的 ​URLconf​：

urlpatterns = [
    path('foo/<int:code>/', my_view),
]

将 ​my_view ​包含在 ​cache_page ​中：

from django.views.decorators.cache import cache_page

urlpatterns = [
    path('foo/<int:code>/', cache_page(60 * 15)(my_view)),
]