协商缓存通过Last-Modified实现，需客户端与服务端两次交互配合：首次响应带Last-Modified头，后续请求自动携带If-Modified-Since头，服务端据此比对时间并返回304或200。
协商缓存通过 Last-Modified 生效，核心在于客户端与服务端**两次交互配合**：首次响应带 Last-Modified 响应头，后续请求自动携带 If-Modified-Since 请求头，服务端据此判断资源是否变更。
服务端如何设置 Last-Modified
服务端在首次返回资源时，需在响应头中写入资源的最后修改时间（GMT 格式）：
- 时间必须是文件系统真实修改时间或业务上可确定的稳定时间戳，不能用当前时间或随机值
- 格式严格为 GMT（非本地时区），例如：
Last-Modified: Wed, 21 Oct 2024 07:28:00 GMT - Node.js（Express）示例：
res.setHeader('Last-Modified', new Date(fileStat.mtime).toUTCString());
浏览器自动发起条件请求
当缓存未过期（且无 Cache-Control: no-cache 等强制禁用行为）时，浏览器再次请求同一 URL 会自动带上请求头：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
If-Modified-Since: Wed, 21 Oct 2024 07:28:00 GMT（值即上次收到的Last-Modified） - 该行为无需前端 JS 主动干预，由浏览器自动完成
- 注意：若资源被强刷（Ctrl+F5）或开发者工具禁用了缓存，则不会发送该头
服务端如何正确响应协商请求
服务端收到 If-Modified-Since 后，需比对时间并返回对应状态码：
立即学习“Java免费学习笔记（深入）”；
- 若资源修改时间 ≤ 请求头中的时间 → 返回
304 Not Modified，响应体为空，可附带新缓存头（如更新后的Cache-Control） - 若资源已更新 → 返回
200 OK，重新返回完整响应体，并更新Last-Modified值 - 关键点：服务端必须解析
If-Modified-Since并做时间比较，不能忽略该头
常见失效原因
即使写了 Last-Modified，协商缓存也可能不生效：
- 服务端未校验
If-Modified-Since，始终返回200（最常见） - 时间精度问题：文件系统只记录到秒级，若 1 秒内多次更新，
Last-Modified无法区分 - CDN 或反向代理（如 Nginx）覆盖或清除了
Last-Modified头 - 响应头被框架/中间件误设为
Cache-Control: no-store或max-age=0
