在查看etag周围的Flask(werkzeug)源码时，发现它生成一个响应对象，通过sha1从数据中生成etag，与请求的if-none-match etag进行比较，返回304或200。因此，无论是否有 etag，访问数据库和创建响应的过程都是相同的，而 etag 的好处就是不必向客户端发送数据。
当然，如果你有大量的数据，那是有好处的，但是如果数据没有那么大，是不是就认为没什么用呢？
与其从每个请求的响应中重新创建etag，我认为最好将etag存储在redis或服务器内存等中，当作为请求目标的对象发生变化时，并在发出请求时将其与预先存储的 etag 进行比较。
这种缓存方式不经常使用吗？
AnETag是一个不透明的、服务器生成的字节序列。HTTP 标准列出了一些可能的实现：
例如，将特定于实现的版本控制应用于所有更改的资源可能会使用内部修订号，可能与内容协商的差异标识符结合使用，以准确区分表示。其他实现可能使用表示内容的抗冲突散列、各种文件属性的组合或具有亚秒级分辨率的修改时间戳。
因此，您可以看到生成响应并计算其哈希值只是众多可能方法中的一种。Nginx、Flask、Django 和其他框架采用这种方法的原因是它是唯一不需要任何特定于应用程序知识的方法。无论如何生成响应，它都保证是准确的。
因此，无论如何，如果您可以使用特定于应用程序的知识（如版本号）来计算 anETag而无需计算响应，那么请随意这样做并享受额外的效率。但是，如果没有这些，哈希方法还是相当不错的：它成本低、潜在的巨大好处（对于大响应），并且不需要开发人员额外的工作。