我正在使用grunt filerev任务在文件内容发生变化时将缓存添加到文件中。 usemin任务将相关文件路径替换为其引用的revved版本。一切都设置得很好，他们按照预期工作/写在他们的文档中。
我现在尝试解释这个问题：
这是一个Angular JS项目，其简化结构有点像这样：
a.html -> b.js -> c.html (partial)
这里a.html引用b.js而b.js将c.html加载为partial。服务器设置为缓存所有这些资产，因此cachebuster字符串变得很重要。
当我运行grunt build执行filerev然后usemin时，它会将c.html重命名为c.[md5_hash_of_c].html，将b.js重命名为b.[md5_hash_of_b].js }和a.html到a.[md5_hash_of_a].html。在此之后，它会将b.js中c.html的参考线更新为c.[md5_hash_of_c].html。同样，它也会更新a.html。这意味着在计算哈希值时，这些文件仍然具有引用的其他文件的未恢复版本。因此，当c.html的内容发生变化时，它会更新b.js中的引用，但不会更新b.js的名称以反映此更改。
这就破坏了在文件名中获取缓存破坏者的目的。由于现在浏览器已缓存b.[md5_hash_of_b].js和a.[md5_hahs_of_a].html，因此更新c.[md5_hash_of_c].html的调用失败。
我在思考角度世界和其他地方，它应该是一个非常标准的做法，但无法在任何地方详细讨论。我正在寻找可以解决这个问题的工作流程。
答案 0 :(得分：1)
在three different places上发现了此问题。第三个链接最接近解决方案。
我最终使用vermin作为filerev和usemin的替换任务，它在内部重复执行这两个任务，直到文件名停止更改。它在这里作为要点分享：https://gist.github.com/markrian/aa185c5ec66232a38a68
来自要点评论：
/**
* Vermin completely manages the running of the filerev and usemin tasks, so
* that assets that reference other assets are correctly hashed after their
* referenced assets are spliced in by usemin.
*
* Vermin also makes various assumptions about how filerev and usemin are set
* up. For instance, it assumes that usemin runs immediately after filerev,
* that filerev renames files in-place, and that usemin relies on
* `grunt.filerev.summary`, as prepared by filerev (which vermin manipulates).
* There may be other implicit assumptions that haven't been identified yet.
*
* Because grunt tasks can only be inserted into the task stack, to be run
* sequentially, vermin recursively adds filerev, usemin and itself to the
* stack to do its work. It maintains its state on the grunt object, and reads
* that on each run to determine where in the process it is.
*/