我能想到的唯一原因是计算ETag 可能很昂贵。如果页面变化很快，浏览器的缓存很可能会被ETag 失效。在这种情况下，计算ETag 将是浪费时间。另一方面，在可能的情况下给出304 响应可以最大限度地减少传输所花费的时间。当使用 Django 的 CommonMiddleware 实现时，ETag 可能成为净赢家时，有哪些好的指导方针？
【问题讨论】：
标签： django performance http caching etag
与任何缓存机制一样，您需要在操作缓存所花费的时间和因此节省的带宽之间进行权衡。
如您所说，如果响应经常变化，ETags 可能不是很有用。 ETags 是一种缓存整个响应的方法，因此如果响应经常更改，实际上不会缓存太多。不过，我猜由于 ETags 很常用，浏览器的实现速度相当快，而且 Django 也可能足够快。
也许在响应之前还有其他区域可以从缓存中受益，例如 memcached。
同样，尝试使用您的真实数据对其进行分析而不是概括为“使用或不使用它”将是有益的。
【讨论】：
有很多方法可以处理缓存，并且通常是特定于应用程序的，我在第一个场景中建议您如何考虑使用来自django.middleware.common.CommonMiddleware 的USE_ETAGS：
在可缓存和不可缓存的 gunicorn 实例之间拆分应用程序。使用反向代理连接站点。然后继续，
编写使模型保存缓存无效的代码。下一步，
编写自己的自定义缓存中间件。
【讨论】：
我不明白你为什么要找一个不做某事的理由。但是，您的分析还远未完成：条件请求/ 304 响应实际上可以使您的应用程序运行速度明显慢于如果您去除 if-modified-since / if-none-match 但它们确实让搜索引擎满意并且有优势服务器-服务器复制（例如在 CDN 上）
C.
【讨论】：