最早在Q群出现一个这样的问题： 缓存更新问题，第一个文件名更换 与第二个文件query更换 哪个更好？
经过FIS(fis.baidu.com)Q群的漂流瓶前辈的解答下有了比较详细的认知。
上图中的第一个 属于 非覆盖式发布 （修改了文件名，这个叫非覆盖式发布，它不会覆盖线上的文件）
第二个 属于 覆盖式发布 （ 同样的文件名，这个叫覆盖式发布，它会覆盖线上的文件）
通过一个举例来证明下那个方式更合适吧：
假设，标红的index.html和a.js是这次修改了的文件，待上线，即将覆盖线上的同名文件对吧
好了，请思考：
对于一个有着1000w日pv的网站，如果要这样上线，是先覆盖a.js呢，还是先覆盖index.html呢
这个时候 问题就变得不好回答了
尤其是当大型网站的静态资源是部署到CDN上的时候，a.js的部署时间，和模板的部署时间间隔非常大
这个期间有很多用户会访问页面，他们最终会得到一个不匹配的页面和静态资源老页面 + 新js 或者 新页面 + 老js这种“细微”的差别，在稍大一些的互联网产品上会被放大，影响深远
这就是 覆盖式带来的问题。
那么现在的答案是 选择 非覆盖式发布
问题又来了： 增量发布，多久清一次文件 （因为md5戳带来的文件名差异 之前的版本还存在于服务器磁盘中）
一个中型产品线，大概每3年会累积200多m的冗余文件，可以考虑清楚一下（ 这个前提是基于md5戳的情况）如果是基于构建版本的，要高很多
1. 文件定位和文件数量没关系，所以文件多了其实也没有什么实质影响
2. 磁盘空间真的很多啊，这个更不用担心了。网站的某个用户，出去玩一次自拍的照片都上传了，所占用的公司服务器磁盘空间应该够产品研发好几年的占用了
3. 打不了写个脚本清理一下，或者用别的什么方式保证一下，总之，非覆盖式发布是目前解决缓存、部署安全等问题的最好方案了，其中以md5戳最优
清除旧文件
你可以保留fis的map.json，然后照着这个清
你也可以写个脚本，按照最后访问时间清
