一、问题描述
公司项目大多是Docker容器化部署，之前的 ci 文件和 ng 配置文件基本没怎么动过，也没有过多关注。最近接手的一个新项目，在部署工作台修改环境变量后，重新部署后，刷新页面没有生效。
（公司的部署工作台项目，这里是写入 docker 的环境变量用来替换打包后的文件的内容的）
在页面中直接展示了该环境变量（没有任何变化，还是上一次的）
二、问题排查
最开始的情况是错误的，环境变量修改后并没有改变。
起初以为是打包的版本有问题，或者是部署脚本的问题。排查后发现别之前的项目同样的 ci文件，同样的 dockerFile并没有什么异常，但是这个项目不行。
打开实时日志，进入容器中查看，发现容器中的需要替换的值已经发生了变化，也就是说服务器上的资源已经改变了。那问题就比较明显了，缓存的问题。
三、问题处理
- 因为项目是内嵌企微的h5，并没有浏览器那种可以直接强制刷新的方式，需要额外的调试工具。
- 打开调试工具之后，设置禁用缓存，再次刷新，果然变了。那么为什么这个项目有问题呢？和另一个项目的区别在什么地方呢？
- 关键点就在于两个项目的 nginx 文件对 http 的缓存设置不同。
四、Nginx 设置 http 缓存
-
之前的项目nginx文件没有设置任何的缓存策略，走的都是公司服务端默认的协商缓存。
-
该项目通过 nginx设置了自己的http 缓存策略
-
所以对于 js 文件设置了强制缓存7天，并且允许被代理服务器进行缓存。
注：这份老的 ng 配置文件是有问题的，no-store和 no-cache 为互斥属性，不可以同时设置
Cache-Control的常用的6个属性:
- max-age： 决定客户端资源被缓存多久。
- s-maxage： 决定代理服务器缓存的时长。
- no-cache： 表示是强制进行协商缓存。
- no-store： 是表示禁止任何缓存策略。
- public： 表示资源即可以被浏览器缓存也可以被代理服务器缓存。
- private： 表示资源只能被浏览器缓存。
所以无论再怎么刷新，再怎么修改环境变量重新部署，只要缓存时间没过期，也没有构建出新的 js 文件的情况下,当前页面对应的 js 文件一直都是第一次请求的(被强制缓存了)。
五、协商缓存解决该问题
- 首先服务器都是公司的，那么暂时默认服务端的缓存设置是有他默认的那一套逻辑，而且业内常用的方式就是无脑协商缓存，至于强制缓存，自行定制。排查后发现本公司也是,没有问题的那个项目里， nginx文件没有任何的缓存设置，服务器默认协商缓存。那么我们可以在 js 文件的地方修改成 Cache-Control:”no-store” 来让它强制走协商缓存。
2.Etag 和 Last-Modified 都有设置。
3.所以当部署工作台环境变量修改之后，直接部署（本次操作是建立才 CI 流程已经完毕，docker 镜像已经构建成功之后。也就是说，这里只在工作台修改环境变量是和项目构建没有任何关系的）。部署之后项目代码中设置的环境变量会发生变化，对应的文件资源也会通过 Etag 的文件指纹感知到。通过Etag 识别该文件已经发生了变化，服务器会返回最新的文件，返回状态码200。所以页面不用刷新就可以生效了。
4.二次刷新，文件资源没有变动，协商缓存依然生效（状态码304）。
六、优化
- 当然Etag 也是有缺陷的。Etag 需要计算文件指纹，这样意味着服务端需要更多的计算开销。
- 而我们需要进行协商缓存的除了一开始的 html 文件之外，还有就是我设置环境变量的文件了。
- 那么我们可以针对这个环境变量的文件进行单独的抽离，通过 webpack将该文件单独拆分，并打上标识。再 nginx 代理的地方进行正则匹配，只针对该文件设置协商缓存，其余的 js文件还是采用业内最常规的强制缓存即可。这样可以连带着服务端的计算开销也省掉了。
- 更多 http 缓存相关问题请移步我的另一篇文章 : 前端缓存
