一、 核心配置优化（前提是访问网站的请求能抵达服务器）

方案一：前端项目设置全局不缓存方案

• 运行逻辑：在H5服务器配置中增加Cache-Control: no-cache或max-age=0响应头，禁用静态资源缓存‌；
• 优点：能在服务器出口处最大可能地解决发布项目缓存问题
• 缺点：用户在不同界面跳转都会重新加载界面信息，影响整个前端加载速度，高并发时容易造成带宽压力

方案二： 首页index.html资源缓存修正，禁制index.html文件缓存

• 优点： 单页面应用设置首页模板强制不缓存，用户浏览器不会缓存 index.html 文件，每次都会向服务器拉取新的首页模板，确保用户不会使用历史模板。
• 缺点： 用户不缓存首页，每次都会拉取，导致每次进入系统都会等待相对较长的时间。

方案三： 首页 index.html 资源添加 ETag和Last-Modified 参数

• ETag：是服务器为资源生成的唯一标识符（如哈希值或版本号），内容变化时标识会更新。
• Last-Modified： 服务器返回资源的最后修改时间戳
• 运行逻辑：客户端首次请求资源时，服务器返回 ETag 和 Last-Modified。后续请求中，客户端可能同时发送 If-None-Match 和 If-Modified-Since。服务器优先检查 ETag 与 Last-Modified（若存在），直接返回 304，浏览器使用缓存文件；因 ETag 精度更高，若匹配，则会忽略 Last-Modified。
• 优点：能检测到内容字节级别的变化或者文件系统时间戳的变化，从而让用户端使用新的文件；通过检验文件的方式实施高效缓存策略，可有效利用客户端缓存，提升网站性能并降低服务器压力。
• 缺点：若多服务器间文件属性或文件时间戳不一致，可能导致 ETag/Last-Modified 冲突（如果是一个jenkins编译，将一个编译包放到两个服务器（服务器系统版本一致）中实现负载均衡，可以使用ETag，如果使用k8s等其他工具发布需要注意文件同步，可以使用分布式文件系统或同步工具）；
  高并发时每一次请求都会检验请求的ETag会占用相对校对的CPU性能（针对目前在线理赔的并发量，可忽略不计）；
  太过于依赖本地缓存，如果请求头校验通过但是本地缓存异常会造成未知异常（目前有人说可能会出现的问题，但是并未在某处真的搜索到相关bug内容）；
  可以用：curl -I https://域名 来查看请求头内容

二、 jenkins发布流程优化方案

• 运行逻辑：每次发布 jenkins 时不删除上一个版本的js文件，直接将新的js放在原有目录下，达到新老版本js共存的目的，当用户使用浏览器缓存的界面读取老版本的js不会因为文件不存在而报错。等待用户浏览器识别到更新后会更新到新版本。

• 优点：
  用户不会因为发布拿不到js文件而白屏，基本可以解决因为发布缓存而白屏的问题。

• 缺点：
  用户使用老版本的js进入系统后，无法使用新功能，如果前后端代码功能不一致会导致用户操作失败；如果用户长时间没有触发更新机制，会导致更新功能在一段时间内用户无法使用；

  随着每次发布，服务器上的js文件会越来越多，当达到一定数量级后会影响服务器对文件的读取速度需要不定时人为处理久远的历史版本（服务器脚本示例，注意不要复制使用，需要根据自己的项目确认删除的数据，数据无价删除许谨慎：保留最近2个版本
  ls -t /path/to/dist/js/app.*.js | tail -n +3 | xargs rm -f）。

三、 使用版本号方案

通过后端更新版本号

• 运行逻辑：后端在系统中开放一个公开接口用于接收并返回当前版本号，前端需要给设备定义一个唯一设备号保存在浏览器；前端每次加载完 index.html 首页模板后，在渲染js之前对后端发起一个版本号对比请求，后端日志保存前端提交请求的版本号与设备号并返回当前系统版本，如果前端本地保存的版本与后端不一致，则前端使用Service Worker缓存控制通过workbox-webpack-plugin清除旧版本文件缓存，然后再刷新界面渲染js。

• 优点：可以在发布代码之后，通过日志查看是否有用户依旧是老版本发起请求，可以通过参数查询同一设备是否在进入老版本后又重新进入了新版本，同时拥有历史日志可以判断设备号属于哪个用户，并且可以人为在数据库修改版本号来实现控制用户刷新次数。

• 缺点：开发测试工作量相对较大，每次发布需要人为修改数据库版本号（或者写成接口放在jenkins中自动触发）；