我一直在阅读有关Etags的文章，并且我了解生成Etag的方法有2种，即弱者和强者。弱Etag在计算上比强Etag更容易生成。我还知道，弱Etags对于大多数用例而言已经足够了。
来自MDN
弱验证器易于生成，但远没有那么有用 比较。强大的验证器是比较的理想选择，但可以 很难高效生成。
另一个摘要：
相同资源的两种表示形式的Etag值可能是 在语义上是等效的，但不是逐字节相同的。
我发现很难理解资源在语义上相似而不是逐字节相同意味着什么？很高兴看到一些例子。
编辑：找到一个示例here，但我不明白：
弱验证：这两种资源表示形式在语义上 等价的一些内容差异并不重要 从业务逻辑的角度来看当前日期显示在 页面对于更新整个资源可能并不重要。
就像生成Etag一样，您可以确定内容的更改对于该功能并不重要（例如，对于字体大小的css属性更改），然后响应304？如果是，那么何时在浏览器上更新资源，我想只要Etag相同，浏览器就不会获得最新版本。在这种情况下，这可能意味着当发生重大更改并创建了新的Etag时，css属性更改才与主要更改一起发送到浏览器。
答案 0 :(得分：1)
我的建议是查看规范RFC 7232, section 2.1。它只有几页长，可以回答您所有的问题。
您要求提供示例，以下是规范中的一些示例：
例如，天气报告的表示形式在 根据动态测量结果，每秒可以对内容进行分组 分为等效表示的集合（来自原始服务器的 透视图）具有相同的弱验证器，以便允许缓存 陈述在一段合理的时间内有效。
表示的修改时间（如果仅用定义） 一秒钟的分辨率，如果可能的话，可能是一个弱验证者 在一秒钟内两次修改表示形式 并在这些修改之间进行检索。
如果原始服务器发送相同的验证器来表示 应用gzip内容编码，就像对没有 内容编码，那么该验证器就很弱。
最后一个代表弱ETag可能是最常见的用法：服务器在对内容进行gzip压缩时将强ETag转换为弱ETag。例如Nginx does this。
该规范还说明了何时更改弱ETag：
只要原始服务器考虑优先，它就应该更改一个弱实体标签 不能替代现行的陈述 表示形式。
换句话说，由您决定资源的两种表示形式是否可以接受。如果是这样，可以通过为它们提供相同的弱ETag来提高缓存性能。