公司前端项目部署现状
将 html 托管给后端，前端只发静态资源（index.js/index.css），然后通过某种方式去刷 html 的静态资源版本号（?version=时间戳或递增数字）。
比较好的实践
我们先来看看前端项目部署的比较好实践是什么？
可以总结出以下四点：
- 配置超长时间的本地缓存 —— 节省带宽，提高性能
- 采用内容摘要作为缓存更新依据 —— 精确的缓存控制
- 静态资源 CDN 部署 —— 优化网络请求
- 变更资源发布路径实现非覆盖式发布 —— 平滑升级
上面文章可是本文的基石，5 年过去了，更好的方案是什么呢，还希望大佬赐教。
作为一个毕业 1 年的菜鸟，我就先着上面的文章来看看目前公司发布流程的不足吧。
公司部署方案优缺点
前端只发布静态资源，只要 html 引用的资源不刷版本号，对老用户是没有影响的（存在强缓存，直接请求本地缓存，对应实践 1），新用户虽然没有缓存，但由于是静态资源是同名覆盖发布，所以请求新的 index.js/index.css 资源，只要资源不依赖 html 结构，看到新版本功能，也没有影响（注意：如果依赖 html 结构，请求新资源可能就会出现问题，好在目前单页应用基本不依赖 html 结构，一个#root 根节点 就够了）。
（强行）优点
- 覆盖发布。服务器不会有大量静态资源文件积累。（这个很重要？）
- 后端可以向 HTML 内注入一些内容，比如用户信息。
缺点
- 粗粒度的版本号刷新策略，导致根据文件内容变化选择性更新缓存（对应实践 2）无法实施
- 覆盖发布。在 html 刷新版本号前，新用户和老用户可能看到的页面版本（功能）不同
- html 托管在后端，导致一定程度的前后端未分离（譬如打包策略变更需要后端配合更改 html）
照猫画虎
那么按照上面的实践，如何处理比较好呢？
- 前端每次基于 content hash（依赖数据摘要算法） 打包生成静态资源文件名(例如
aaa.[contenthash].js与bbb.[contenthash].css)，文件名是否变化取决于文件内容是否变化 - 使用前端的 html，前端可在打包过程中自动注入静态资源文件地址
- 静态资源先发布，html 后发布
再来看看上面的缺点是否被解决了？
1. 粗粒度的版本号刷新策略，导致根据文件内容变化选择性更新缓存（对应实践 2）无法实施
文件名是基于 content hash生成，在发布新的 html 后，若文件内容未发生变化，文件名不会发生改变，依旧使用本地强缓存，若文件内容变化，文件名会发生改变，会请求新的静态资源，达到了选择性更新缓存的效果。
2. 覆盖发布。在 html 刷新版本号前，新用户和老用户可能看到的页面版本（功能）不同
非覆盖式发布，文件名[contenthash]不同不会覆盖，旧的静态资源文件依旧存在。
新的静态资源发布后，新的 html 未发布前这个时间段内，老用户请求到旧的 html，请求的是旧的静态资源，文件名(或者说文件路径)未变化，依旧使用本地强缓存，新用户请求到旧的 html，没有本地缓存，但旧的静态资源未被覆盖，依旧可以请求到，此时看到的都是旧版本内容。
新的 html 发布后，老用户浏览器会选择性更新本地缓存，新用户直接请求新的静态资源，看到的都是新版本内容。
3. html 托管在后端，导致一定程度的前后端未分离（譬如打包策略变更需要后端配合更改 html）
html 完全由前端控制，后端只需要提供 API 即可，前后端真正意义上的完全分离。
缺点：
- 发生变化的文件 hash 值不同，非覆盖发布，可能造成服务器上无用的静态资源越来越多，但这是可以解决的
- 后端不能往 html 注入一些内容
结语
经验浅了些，参考的资料古老了些，可能有些地方有失偏颇，请一定要指正。
而且项目上线是肯定要配 Nginx 的，要去找运维帮忙配，流程上还有可以优化的地方，现在这种形式对前端制约太大了。
