这样一个需求, 有文件 a.html b.css, a 当中有 b 的依赖.
然后上线了, 为了做 CDN, 我们调整文件名 a.<md5>.html, b.<md5>.html.
这时候比如说 b 变了, 那么 b.md5.css 这个也变了, 实际上, a.<md5>.html 也变了.
因为 a 相当于引用了一个 b 的文件名, 而 b 的文件名因为内容改了也就变了...
我们使用 md5 就是为了文件内容唯一..
然后, 这样递归生成 md5 压力比较大, 我考虑这样一个策略,
不是把 b.<md5>.css 替换进 a 再去计算 a 的 md5,
而是把 a 的 md5 加上 b 修改了名字之后的 md5. 两个 md5 一起生成新的 md5.
用这样的方案进行上线, 静态资源是否还能保持唯一呢?
这不是循环了么？
其实，直接构建的时候拉git的commit hash就好了，直接截取前半部分的话还具备天然的从
构建后的文件名找对应的commit的功能，多好
好奇怪，你听谁说的MD5能保证唯一？
这要看你的md5值是用来做什么的。从你描述的情况来看，文件名里的md5只是为了保证文件被更改后产生一个新的文件名来使强制cdn刷新。md5值本身并不用来做验证，那么你说的方法是可行的。
但是用你的方法会有几个问题：
如果b改回去了，b的文件名会被改回去，理论上a的文件名也应该改回去，但用你的方法虽然a的内容没变（被改回去了）但是文件名上的md5却变了。所以会出现文件名不同但内容相同的情况。
如果a有两个依赖b和c。当b,c都改动的时候，md5(md5(a)+md5(b)+md5(c))和md5(md5(a)+md5(c)+md5(b))是不一样的，取决于顺序。这其实不会影响你的目的（使文件名发生改动），但看上去怪怪的。
文件名不可预测。
其实算MD5很快，而且只是发布的时候做一次功而已，不用搞这么复杂。