无痕模式下缓存策略仍生效，强缓存（cache-control/expires）可命中from memory/disk cache，协商缓存（etag/last-modified）照常发起条件请求并接收304；真正受限的是localstorage、indexeddb及service worker持久化缓存。
无痕模式下验证缓存策略，关键不是“看它缓不缓”，而是确认你的缓存头是否被浏览器正确解析和执行——因为无痕模式本身不阻止缓存逻辑运行，但会清空持久缓存、禁用部分存储 API，并重置 Service Worker 状态。
先确认无痕模式是否真影响缓存行为
很多开发者误以为“无痕 = 不缓存”，其实不然：
- 强缓存（
Cache-Control/Expires）在无痕窗口中依然生效：资源仍可能显示from memory cache或from disk cache - 协商缓存（
ETag/Last-Modified）也照常发起条件请求，服务器可正常返回304 Not Modified - 真正被限制的是持久化存储：
localStorage、indexedDB、Cache API（Service Worker 控制的缓存）在关闭窗口后即丢弃，但加载过程中的缓存判断不受影响
在无痕模式下验证缓存头是否生效
打开无痕窗口 → 访问目标页面 → 打开开发者工具（F12）→ 切换到 Network 标签页 → 刷新页面：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 选中一个 JS/CSS 资源，查看 Response Headers：确认存在
Cache-Control（如max-age=31536000, public）或Expires - 观察 Size 列：若显示
from memory cache或from disk cache，说明强缓存已命中 - 若第二次请求仍发起了完整响应（Size 显示具体 KB 数且状态码是 200），检查是否被以下干扰：
- 开发工具勾选了 “Disable cache”（务必取消勾选）
- 资源 URL 带时间戳或哈希变化（如
app.js?v=123），导致每次都是新请求 - 服务器未返回缓存头，或返回了
Cache-Control: no-store/no-cache
重点验证 Service Worker 缓存是否兼容无痕
Service Worker 在无痕模式下有特殊行为：
- Chrome/Firefox 中，无痕窗口会为每个会话创建独立的 SW 实例，关闭即销毁；Safari 甚至默认禁用无痕下的 SW
- 因此需在 Application → Service Workers 面板中确认：
- SW 是否成功注册（Registration status:
active） - 点击 “Update on reload”，刷新后观察是否触发
install→activate流程 - 在 Cache Storage 下查看是否有缓存写入（如
my-precache-v1）
- SW 是否成功注册（Registration status:
- 若缓存未写入，检查 SW 脚本中是否做了无痕环境判断（如检测
navigator.webdriver或尝试访问indexedDB失败），应避免依赖持久存储做缓存主逻辑
规避无痕导致的“假失效”误判
不要用 localStorage 是否可用来反推缓存是否生效——它在无痕中通常仍可读写（只是不持久），容易得出错误结论。更可靠的方式是：
- 用
fetch()请求同一资源两次，对比两次响应的headers.get('date')和headers.get('last-modified')是否一致（强缓存下后者不变） - 监听
performance.getEntriesByType('resource')，检查transferSize是否为 0（表示未传输，走缓存） - 服务端配合日志：对带
If-None-Match的请求打标，确认协商缓存是否真实触发
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
