用时间做版本标识
Last-Modified 是资源最后一次修改的绝对时间，精度到秒，用 GMT 表示。它主要服务两件事：一是配合 If-Modified-Since 做缓存再验证，资源没变就回 304，省掉响应体的传输；二是作为 If-Range 的备选校验值，判断断点续传是否还成立。它的弱点也很明显：一秒内多次修改无法区分，而且这个时间由服务端给出、可能被回拨。
基本信息
| 响应头名 | Last-Modified |
|---|---|
| 格式 | GMT 时间字符串，如 Sat, 11 Oct 2026 12:00:00 GMT |
| 规范 | RFC 9110 第 8.8.2 节 |
| 配合请求头 | If-Modified-Since 做再验证，If-Range 做续传校验 |
| 精度 | 秒级，同一秒内的多次修改无法区分 |
| 与 ETag 的关系 | 两者同时存在时，缓存校验优先使用 ETag |
查看与再验证
查看与再验证
curl -sI https://www.example.com/ | grep -i last-modified # 看资源最后修改时间
curl -sI https://www.example.com/ | grep -iE 'etag|date' # 与 ETag 和 Date 一起对比判断
curl -si -H 'If-Modified-Since: Sat, 11 Oct 2026 12:00:00 GMT' https://www.example.com/ | head -1 # 未变更应回 304
curl -si -r 0-99 -H 'If-Range: Sat, 11 Oct 2026 12:00:00 GMT' https://download.example.com/f.bin | head -1 # 变更时应退回 200典型使用场景
- 静态资源再验证：本地副本过期后带上时间回源，未更新则回 304 省流量
- 断点续传校验：确认文件仍是下载开始时的那个版本
- 运维核对发布时间：比 ETag 更直观，适合人工判断
- 增量同步任务：按修改时间筛选需要处理的文件
- 排查缓存不刷新问题：对比服务端时间、Date 头与本地副本时间
输出逐列读法
| 字段 | 含义 | 怎么看 |
|---|---|---|
| Last-Modified | 资源最后修改时间 | 与 Date 头对比，明显早于响应时间属于正常 |
| Date | 响应生成时间 | 用于判断中间缓存是否复用了旧响应 |
| If-Modified-Since | 客户端携带的期望时间 | 服务端比较后决定回 304 还是 200 |
| 304 Not Modified | 未变更，复用本地副本 | 不返回响应体，但会刷新本地副本的新鲜度 |
| 时间回拨 | Last-Modified 反而变新或变旧 | 构建流程与文件拷贝顺序都可能造成，注意比对 |
只做展示时 Last-Modified 更直观；做精确缓存校验时应优先 ETag。两者同时存在且同时提供时，服务端按规范优先使用 ETag 判断。