Django 包含一个灵活的缓存框架，支持多个缓存级别（整个页面、视图结果、模板片段或任意数据）和多个后端（内存、Redis、Memcached、数据库）。缓存避免了重复的昂贵工作——这是性能优化中影响最大的方法之一。
# settings.py — Redis is the common production choice (shared across servers)
CACHES = {
"default": {
: ,
: ,
}
}
# 1. Per-view caching — cache an entire view's output
from django.views.decorators.cache import cache_page
@cache_page(60 * 15) # cache this view's response for 15 minutes
def article_list(request):
...
<!-- 2. Template fragment caching — cache part of a template -->
{% load cache %}
{% cache 500 sidebar %}
... expensive sidebar rendering ... <!-- cached for 500 seconds -->
{% endcache %}
# 3. Low-level cache API — cache ANY data, full control
from django.core.cache import cache
def get_stats():
stats = cache.get("dashboard_stats") # check cache first
if stats is None: # cache MISS
stats = compute_expensive_stats() # do the work
cache.set("dashboard_stats", stats, 3600) # store for 1 hour
return stats
Django 让你在多个粒度级别进行缓存：整个页面（cache_page）、模板片段（{% cache %}）和任意数据通过低级 API（cache.get/cache.set — 灵活的 get-or-compute 模式）。还有通过中间件进行全站缓存。
# when underlying data changes, the cache must be updated or cleared, or users see stale data
def update_article(article):
article.save()
cache.delete("article_list") # invalidate affected cache entries
# strategies: TTL (accept brief staleness), explicit deletion on writes, versioned keys,
# or signals to invalidate on model save/delete
Cache invalidation is the classic hard problem: when data changes, stale cached
values must be cleared/refreshed. Approaches: short TTLs (accept some staleness),
explicit cache.delete on writes, or cache versioning/key schemes.
✓ Expensive queries/computations, rendered pages/fragments that change infrequently
✓ Aggregations, external API responses, session data
✗ Highly personalized or rapidly-changing data (or use very short TTLs / vary per user)
✗ Don't cache sensitive data carelessly (consider who can read the cache)
缓存是 Django 应用程序性能优化中影响最大的方法之一，框架的全面、多级缓存系统使其易于使用——理解它对于构建快速、可扩展的应用程序是宝贵的高级知识。
核心价值是避免重复的昂贵工作：数据库查询、复杂计算、外部 API 调用和模板渲染可以被缓存，这样后续请求就能快速提供，大大降低延迟和数据库/服务器负载。
Django 在多个缓存级别上的灵活性（使用 cache_page 的整个页面、使用 {% cache %} 的模板片段和通过低级 API 的 get-or-compute 模式的任意数据）让你在每种情况下以恰当的粒度进行缓存，其可插拔的后端（特别是Redis用于多个服务器间的共享缓存——重要是因为当水平扩展时，单进程内存缓存不被共享）适合不同的部署需求。
了解如何配置缓存、选择适当的级别并为部署选择正确的后端是实用的、经常需要的知识。
同样重要的是理解缓存的核心难点——失效（著名的清除或刷新缓存数据的困难问题，当底层数据改变时，通过 TTL、写入时显式删除或密钥版本控制，以避免提供过时数据）——因为做错这一点是经典的缓存失败，会向用户显示过时的信息。
同样知道缓存什么（昂贵的、不经常改变的数据）与不缓存什么（高度动态或敏感数据）是有效使用缓存的关键。
因为缓存提供了重大的性能收益，但需要谨慎的失效处理，掌握 Django 的缓存框架——级别、后端，特别是失效策略——对于构建高性能、可扩展的应用程序是重要知识，也是能让 Django 应用在真实负载下快速运行的开发者的标志。