公司前台项目部署现状

将 html 托管给后台，前台只发静态资源（index.js/index.css），而后通过某种方式去刷 html 的静态资源版本号（?version=时间戳或者递增数字）。

比较好的实践

我们先来看看前台项目部署的比较好实践是什么？

出处：大公司里怎么开发和部署前台代码？

可以总结出以下四点：

1. 配置超长时间的本地缓存 —— 节省带宽，提高性能
2. 采用内容摘要作为缓存升级依据 —— 准确的缓存控制
3. 静态资源 CDN 部署 —— 优化网络请求
4. 变更资源发布路径实现非覆盖式发布 —— 平滑更新

上面文章可是本文的基石，5 年过去了，更好的方案是什么呢，还希望大佬赐教。

作为一个毕业 1 年的菜鸟，我就先着上面的文章来看看目前公司发布流程的不足吧。

公司部署方案优缺点

前台只发布静态资源，只需 html 引用的资源不刷版本号，对老客户是没有影响的（存在强缓存，直接请求本地缓存，对应实践 1），新客户尽管没有缓存，但因为是静态资源是同名覆盖发布，所以请求新的 index.js/index.css 资源，只需资源不依赖 html 结构，看到新版本功能，也没有影响（注意：假如依赖 html 结构，请求新资源可能就会出现问题，好在目前单页应用基本不依赖 html 结构，一个#root 根节点 就够了）。

（强行）优点

1. 覆盖发布。服务器不会有大量静态资源文件积累。（这个很重要？）
2. 后台可以向 HTML 内注入少量内容，比方客户信息。

缺点

1. 粗粒度的版本号刷新策略，导致根据文件内容变化选择性升级缓存（对应实践 2）无法实施
2. 覆盖发布。在 html 刷新版本号前，新客户和老客户可能看到的页面版本（功能）不同
3. html 托管在后台，导致肯定程度的前后台未分离（譬如打包策略变更需要后台配合更改 html）

照猫画虎

那么按照上面的实践，如何解决比较好呢？

1. 前台每次基于 content hash（依赖内容摘要算法） 打包生成静态资源文件名(例如 aaa.[contenthash].js 与 bbb.[contenthash].css)，文件名能否变化取决于文件内容能否变化
2. 使用前台的 html，前台可在打包过程中自动注入静态资源文件地址
3. 静态资源先发布，html 后发布

再来看看上面的缺点能否被处理了？

1. 粗粒度的版本号刷新策略，导致根据文件内容变化选择性升级缓存（对应实践 2）无法实施

文件名是基于 content hash（依赖内容摘要算法）生成，在发布新的 html 后，若文件内容未发生变化，文件名不会发生改变，仍旧使用本地强缓存，若文件内容变化，文件名会发生改变，会请求新的静态资源，达到了选择性升级缓存的效果。

2. 覆盖发布。在 html 刷新版本号前，新客户和老客户可能看到的页面版本（功能）不同

非覆盖式发布，文件名[contenthash]不同不会覆盖，旧的静态资源文件仍旧存在。

新的静态资源发布后，新的 html 未发布前这个时间段内，老客户请求到旧的 html，请求的是旧的静态资源，文件名(或者者说文件路径)未变化，仍旧使用本地强缓存，新客户请求到旧的 html，没有本地缓存，但旧的静态资源未被覆盖，仍旧可以请求到，此时看到的都是旧版本内容。

新的 html 发布后，老客户浏览器会选择性升级本地缓存，新客户直接请求新的静态资源，看到的都是新版本内容。

3. html 托管在后台，导致肯定程度的前后台未分离（譬如打包策略变更需要后台配合更改 html）

html 完全由前台控制，后台只要要提供 API 就可，前后台真正意义上的完全分离。

缺点：

• 发生变化的文件 hash 值不同，非覆盖发布，可能造成服务器上无用的静态资源越来越多，但这是可以处理的
• 后台不能往 html 注入少量内容

结语

经验浅了些，参考的资料古老了些，可能有些地方有失偏颇，请肯定要指正。

而且项目上线是一定要配 Nginx 的，要去找运维帮忙配，流程上还有可以优化的地方，现在这种形式对前台制约太大了。