假设一个工作台允许同一浏览器切换账号。退出甲账号再登录乙账号，页面一闪而过的仍是甲的项目。把所有问题都归结为“浏览器缓存”并设置一个响应头，可能修不到真正保留数据的位置。
MDN 区分了几个容易混淆的 HTTP 缓存指令：no-cache 允许存储，但复用前需要验证；no-store 要求不存储响应；private 允许私有缓存、限制共享缓存。它们描述的是 HTTP 缓存行为，不等同于清空应用内存、离线存储或所有历史页面状态。
我建议先列出这份数据经过的层：服务端或 CDN、浏览器 HTTP 缓存、前端查询缓存、页面组件状态，以及产品确实使用的 Service Worker 存储。不是每个产品都有全部这些层，排查应从实际实现出发。看到旧项目时，同时记录网络有没有请求、请求属于哪个身份、响应是否含旧数据。
若响应正确而页面错误，重点检查前端缓存键是否包含账号或租户范围、退出时是否清理相应状态。若页面在响应到达前短暂展示旧内容，还要检查切换期间的占位逻辑。若旧请求较晚返回，必须避免把甲账号请求的结果写进乙账号页面。这些是基于身份切换的工程推导，不是本篇对某个产品的实测结论。
可以用两个仅含假数据的测试账号验收：甲有红色项目，乙有蓝色项目。依次尝试正常切换、慢网切换、多个标签页、后退前进和重新打开。每次分别检查画面与接口。历史导航可能恢复页面快照，不能仅靠 no-cache 就宣称所有返回路径都会重新校验。
服务端访问控制要独立成立。即使界面已经清空，乙账号也不应凭猜到甲项目的标识获取数据；反之，服务端拒绝访问，也不能自动消除前端残留画面。两类验收解决不同问题，缺一项就容易误判修复完成。
最终可以把责任写清：哪些响应允许缓存、缓存归属哪个身份、退出时清理哪些存储、旧请求如何失效、历史恢复时如何校验。无需为了这一个场景禁止所有静态资源缓存，但涉及用户身份的数据必须有明确生命周期。
资料：MDN Cache-Control；页面标注更新 2026-09-17。查阅日期：2026-11-05（Asia/Shanghai）。
来源：https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Cache-Control
