我们的应用程序中有数百个 JavaScript 文件，这些文件目前正在未压缩的状态下提供。我们获得更多客户端性能的解决方案之一是缩小我们的 javascript 文件。我已经创建了一个自动化解决方案来在构建中执行此操作，但是，当部署这些新文件时，确定是否将其重新发送给客户端的文件时间戳将被更改。这意味着，在以后的每个版本中，所有的 javascript 文件都会有一个新的时间戳。我们的客户将再次重新下载所有缩小的 javascript 文件，从而破坏缩小的性能方面。
这是其他人遇到的问题吗？你的解决方案是什么？您是否在项目中使用了单独的非缩小和缩小 javascript 文件，并且不对构建执行缩小？
我们考虑了其他解决方案（例如仅在源代码控制存储库中查找实际更改的文件），但这是我想了解其他人在做什么的一个问题。
您将必须确定哪些文件实际已更改。或者只是不用担心，享受通过缩小文件获得的改进。无论如何，客户端可能不会将文件保存在缓存中很长时间，因此除非您非常非常频繁地更新文件，否则尝试管理缓存行为可能收效甚微。
您可以编写一个脚本来检查源文件夹和目标文件夹中每个文件的 CRC 或 MD5 哈希，并且仅在文件已更改时才执行覆盖。这将保留未更改文件的时间戳，从而为您提供所需的缓存行为。
同样，您可以记录前一个时间戳，进行覆盖，然后使用 touch 命令（假设这些文件位于 unix 系统上）将时间戳设置回其原始值。
第一个选项可能更好，而不是一直盲目地将时间戳设置为相同的值，因为这可能意味着某些客户端暂时不会拾取修改后的 JS 文件，因为服务器声称它没有更改。
您可以在一段时间内推出这些脚本文件，这样单个用户请求就不会花费过多的时间。但说真的，我们在谈论多少 javascript？一次性重新下载与您的页面相关的脚本真的有那么大吗？想想你要付出多少努力才能完成这件事，并权衡它的好处。
阅读由 Flickr 成名的 Cal Henderson 撰写的http://www.thinkvitamin.com/features/webapps/serving-javascript-fast 。希望你会发现它很有用。