很多人觉得HTTPS只是给网站加了个小绿锁，安全了就万事大吉。但实际开发和运维中，HTTPS对缓存的影响常常被忽略，结果就是页面加载变慢、资源重复请求、CDN没生效，甚至用户看到的还是旧版本。
HTTPS默认不缓存？别被误导
其实HTTPS本身并不禁止缓存。问题出在配置上。很多开发者以为只要上了HTTPS，缓存策略就能照搬HTTP那一套，结果发现浏览器根本不买账。原因往往是服务器返回的响应头里，Cache-Control 或 Expires 没设置好，或者被反向代理、CDN中间层悄悄改掉了。
比如你在Nginx里配了缓存，但用了HTTPS后，前端加了个负载均衡器，它默认把所有HTTPS响应都标成不可缓存，那用户每次打开页面都得重新下载JS和CSS，手机流量蹭蹭涨。
混合内容导致缓存失效
一个HTTPS页面里，如果还偷偷加载了HTTP的图片或脚本，浏览器会直接拦截或警告。这种“混合内容”不仅不安全，还会让资源无法进入缓存。用户刷新页面时，那些被拦截的资源还得再试一次，拖慢整体速度。
常见场景是老项目迁移HTTPS时，忘了改静态资源链接。比如HTML里写的是
<img src="http://cdn.example.com/logo.png" alt="logo">CDN缓存HTTPS资源要注意协议一致性
用CDN加速HTTPS站点时，源站和CDN之间的回源协议也得留意。有些CDN默认用HTTP回源，即使你网站是HTTPS的。这时候如果源站强制跳转HTTPS，就会造成重定向循环或回源失败，CDN拿不到内容，也就没法缓存。
正确做法是确保CDN配置为HTTPS回源，同时检查源站证书是否被CDN信任。否则用户请求一个图片，CDN没法从源站拉到，只能每次都穿透到底层服务器，压力全跑后端去了。
Cookie和认证头影响缓存命中
带登录状态的请求通常附带Cookie或Authorization头，这类请求默认不会被浏览器或CDN缓存。如果你把所有资源都放在需要鉴权的路径下，哪怕是一张公共图标，也会变成“每个用户单独请求”，完全失去共享缓存的意义。
建议把静态资源（JS、CSS、图片）放在独立域名或公开路径下，避免携带敏感头。比如用 static.yoursite.com 托管所有静态文件，并关闭该域名的Cookie写入，这样CDN才能高效缓存。
缓存清理别只盯着URL
HTTPS环境下，同一个资源可能通过不同域名或路径访问。比如你更新了app.js，清了主站的CDN缓存，但忘记另一个备用域名也在用同一份文件，结果部分用户还在跑旧逻辑。更麻烦的是，HTTP/2和CDN边缘节点可能有多个缓存层级，光刷新源站没用。
上线前记得确认所有可能的访问路径，必要时使用版本化文件名，比如 app-v2.1.0.js，靠名字变化绕过旧缓存，比依赖缓存失效机制更靠谱。