如何排查缓存相关问题？SSO登录后提交修改不生效故障诊断

DevTools的Application > Cache面板仅展示已废弃的App Cache、Service Worker使用的Cache Storage内容，你遇到的缓存大概率属于以下几类，不会在该面板展示：

• 浏览器HTTP响应缓存：基于Cache-Control、ETag、Last-Modified等响应头控制，是浏览器默认的通用缓存机制，存储在本地HTTP缓存池
• ASP.NET服务端输出缓存：服务端会直接存储渲染好的页面/接口响应，匹配到相同请求时不执行业务逻辑直接返回缓存内容
• 代理/网关缓存：包括公司内网代理、CDN、SSO身份网关自带的缓存逻辑，缓存在中间服务节点
• Ajax默认缓存：GET类型的Ajax请求在未禁用缓存时，浏览器会默认缓存响应内容

• 打开DevTools的Network面板，勾选顶部的Disable cache选项后复现操作，如果问题直接消失，可确认是缓存类问题
• 查看异常请求的状态码：如果标注为200 OK (from disk cache)或200 OK (from memory cache)，说明命中了浏览器本地HTTP缓存
• 提交修改后直接在无痕模式新窗口打开目标页面，如果展示的还是旧内容，可确认是服务端缓存或中间代理缓存导致
• 对比SSO登录和非SSO登录场景下的请求响应头，重点查看Cache-Control、Vary、ETag等缓存相关头，以及身份类Cookie/Authorization头的差异：如果SSO登录后响应头的Vary未包含身份标识字段，会导致不同用户拿到同一份缓存响应

SSO登录和非SSO登录属于不同身份的请求，ASP.NET默认OutputCache如果没有配置按用户身份（Cookie/Authorization头）区分缓存键，会把两类请求判定为相同请求，直接返回旧的缓存内容，就会出现修改后刷新不生效的情况。你计划添加的三类配置分别对应关闭服务端输出缓存、禁止客户端/代理缓存页面、禁用Ajax请求缓存，确实可以覆盖绝大多数这类场景的问题。

• 第一步：确认请求来源：给异常请求的URL手动加随机后缀比如?t=随机数字，如果加后缀后问题消失，即可确定为缓存问题
• 第二步：对比异常请求和正常请求的所有头信息，重点排查缓存相关响应头、身份类请求头的差异，定位是哪一层缓存未按身份区分内容
• 第三步：排查服务端配置：包括OutputCache全局/局部配置、业务代码内自定义的内存缓存/Redis缓存逻辑，确认是否存在缓存键未包含用户身份标识的问题
• 第四步：排查中间层配置：如果使用了SSO网关、CDN、反向代理，确认这些节点是否开启了缓存，是否存在未按用户身份区分缓存的配置

内容的提问来源于stack exchange，提问作者Greg