习惯了前后端完全分离的开发模式，一时难以接受前端 html 托管在后端这种操作。

公司前端项目部署现状

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

原因：HTML 文件不能放在 CDN 上，会被缓存。

比较好的实践

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

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

可以总结出以下四点：

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

上面文章可是本文的基石，虽然已经过去了 5 年。

公司部署方案优缺点

前端只发布静态资源，只要 html 引用的资源不刷版本号，请求的都是 CDN 上缓存的资源（如果 CDN 有缓存的话）。

（强行）优点

  1. 覆盖发布。服务器不会有大量静态资源文件积累；
  2. 后端可以向 HTML 内注入一些内容，比如用户信息。

缺点

  1. 粗粒度的版本号刷新策略，导致根据文件内容变化选择性更新缓存（对应实践 2）无法实施；
  2. 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 ，流程上还有可以优化的地方。