公司前端项目部署现状

将 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 的，要去找运维帮忙配，流程上还有可以优化的地方，现在这种形式对前端制约太大了。