HTTP标头中的ETag实际上如何工作？

Question

如果要处理其他问题，我不知道我是否无法正确理解ETags的缓存方面，但是我将带您了解我的情况。

根据我的理解，ETag是基于文件信息创建的唯一哈希，它们作为Response标头的一部分发送，以唯一地标识文件。如果文件被更新，则信息被改变，因此文件的ETag也被改变。

在我的项目中，每次更改文件时都需要获取一个新的JS文件。我不能使用版本标签或唯一的哈希作为文件名的一部分。我以为ETag可以在哪里工作

                 Http Request 
                 GET myFile.js
        Client ------------------> SERVER
                 Http Response 200
                 Http Response Header
                      accept-ranges: bytes
                      cache-control: max-age=86400, public
                      etag: "a7-58c3bb52101c4"
                      ......

                     myFile.js
        Client <------------------ SERVER


        // myFile.js has not been changed

                 Http Request 
                 GET myFile.js
        Client ------------------> SERVER
                 Http Response 304
                 Http Response Header
                      accept-ranges: bytes
                      cache-control: max-age=86400, public
                      etag: "a7-58c3bb52101c4"
                      ......
        Client uses cached version of file

        // myFile has been changed

                 Http Request 
                 GET myFile.js
        Client ------------------> SERVER
                 Http Response 200
                 Http Response Header
                      accept-ranges: bytes
                      cache-control: max-age=86400, public
                      etag: "88-58c3a1cb8474f" // new etag generated
                      ......

                     myFile.js
        Client <------------------ SERVER

因此，如果再次请求文件且未进行任何更改，则etag将保持不变，并且将获得304指示应使用缓存的版本。

如果文件已更改，则etag也将有所不同，并且服务器将发送文件的新副本。

这就是我期望它能工作的方式。

我的问题： 当我更新myFile.js时，好像再也没有收到新的ETag。它只是默认为文件的缓存版本。如果清除缓存，则会得到最新文件和新的ETag。在我看来，这似乎失败了。这是如何工作的还是我在这里理解不正确？