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