关于缓存剩下的问题是数据的隐私性以及在级联缓存中数据应该在何处储存的问题。
通常用户将会面对两种缓存： 他或她自己的浏览器缓存（私有缓存）以及他或她的提供者缓存（公共缓存）。 公共缓存由多个用户使用，而受其他某人的控制。 这就产生了你不想遇到的敏感数据的问题，比如说你的银行账号被存储在公众缓存中。 因此，Web 应用程序需要以某种方式告诉缓存那些数据是私有的，哪些是公共的。
解决方案是标示出某个页面缓存应当是私有的。 要在 Django 中完成此项工作，可使用 cache_control 视图修饰器： 例如：
from django.views.decorators.cache import cache_control @cache_control(private=True) def my_view(request): # ...</div>
该修饰器负责在后台发送相应的 HTTP 头部。
还有一些其他方法可以控制缓存参数。 例如, HTTP 允许应用程序执行如下操作:
- 定义页面可以被缓存的最大时间。
- 指定某个缓存是否总是检查较新版本，仅当无更新时才传递所缓存内容。 （一些缓存即便在服务器页面发生变化的情况下仍然会传送所缓存的内容，只因为缓存拷贝没有过期。）
在 Django 中，可使用 cache_control 视图修饰器指定这些缓存参数。 在本例中， cache_control 告诉缓存对每次访问都重新验证缓存并在最长 3600 秒内保存所缓存版本：
from django.views.decorators.cache import cache_control @cache_control(must_revalidate=True, max_age=3600) def my_view(request): # ...</div>
在 cache_control() 中，任何合法的Cache-Control HTTP 指令都是有效的。下面是完整列表：
public=True private=True no_cache=True no_transform=True must_revalidate=True proxy_revalidate=True max_age=num_seconds s_maxage=num_seconds</div>
缓存中间件已经使用 CACHE_MIDDLEWARE_SETTINGS 设置设定了缓存头部 max-age 。 如果你在cache_control修饰器中使用了自定义的max_age，该修饰器将会取得优先权，该头部的值将被正确地被合并。
如果你想用头部完全禁掉缓存，django.views.decorators.cache.never_cache装饰器可以添加确保响应不被缓存的头部信息。 例如：
from django.views.decorators.cache import never_cache @never_cache def myview(request): # ...</div>
其他优化
Django 带有一些其它中间件可帮助您优化应用程序的性能:
- django.middleware.http.ConditionalGetMiddleware 为现代浏览器增加了有条件的，基于 ETag 和 Last-Modified 头标的GET响应的相关支持。
- django.middleware.gzip.GZipMiddleware 为所有现代浏览器压缩响应内容，以节省带宽和传送时间。
MIDDLEWARE_CLASSES 的顺序
如果使用缓存中间件，注意在MIDDLEWARE_CLASSES设置中正确配置。 因为缓存中间件需要知道哪些头部信息由哪些缓存区来区分。 中间件总是尽可能得想Vary响应头中添加信息。
UpdateCacheMiddleware在相应阶段运行。因为中间件是以相反顺序运行的，所有列表顶部的中间件反而last在相应阶段的最后运行。 所有，你需要确保UpdateCacheMiddleware排在任何可能往Vary头部添加信息的中间件之前。 下面的中间件模块就是这样的：
- 添加 Cookie 的 SessionMiddleware
- 添加 Accept-Encoding 的 GZipMiddleware
- 添加Accept-Language的LocaleMiddleware
另一方面，FetchFromCacheMiddleware在请求阶段运行，这时中间件循序执行，所以列表顶端的项目会首先执行。 FetchFromCacheMiddleware也需要在会修改Vary头部的中间件之后运行，所以FetchFromCacheMiddleware必须放在它们后面。
</div>