Nginx 默认对静态文件自动启用 Last-Modified，基于文件 mtime 生成标准 GMT 格式响应头；需确保部署不破坏时间戳、禁用手动 add_header 覆盖、配合合理 Cache-Control，并通过 if_modified_since 控制比对逻辑，最后用 curl 验证 304 响应。
Nginx 对静态文件默认就支持 Last-Modified，不需要额外开启——只要资源是直接由 Nginx 服务（比如 .js、.css、.png 等真实磁盘文件），它会自动读取文件系统中的 mtime，并以标准 RFC 1123 格式（如 Mon, 15 Jul 2026 09:45:22 GMT）写入响应头。
关键不是“怎么配出来”，而是“怎么让它真正生效、不被干扰”。
确保 Last-Modified 正常生成
- Nginx 默认对静态文件启用
last_modified on;（无需手动加，除非你显式关过） - 文件必须有真实、可信的修改时间：部署时避免用
cp覆盖却不更新 mtime；推荐用rsync -a或 CI 中加touch重置时间戳 - 不要手动用
add_header Last-Modified ...覆盖——这会破坏自动机制，且容易格式错误（非 GMT 格式会被浏览器忽略）
让客户端能正确发起协商请求
- 浏览器只在强缓存过期后才自动带
If-Modified-Since - 所以需配合合理的
Cache-Control或Expires：- 对无版本号的通用资源（如
logo.png）：expires 1h;add_header Cache-Control "public, must-revalidate"; - 对带哈希的版本化资源（如
app.a1b2c3.js）：expires 1y;add_header Cache-Control "public, immutable";
- 对无版本号的通用资源（如
控制 If-Modified-Since 的比对逻辑
Nginx 提供 if_modified_since 指令，决定时间比较方式：
-
if_modified_since exact;（默认）
仅当服务端当前mtime与客户端If-Modified-Since毫秒级完全一致时才返回 304。最保守，适合多数场景。 -
if_modified_since before;
只要服务端mtime ≤客户端时间，就返回 304。更宽松，适合希望提升 304 命中率、且能接受“略旧但未变”的情况。
该指令可放在 http、server 或 location 块中，例如：
location ~* \.(js|css|png|jpg|gif)$ {
if_modified_since before;
}验证是否生效
用 curl 检查真实响应头：
curl -I https://your-site.com/static/main.css
确认返回中包含类似：
Last-Modified: Thu, 20 Aug 2026 14:32:11 GMT Cache-Control: public, must-revalidate
再模拟条件请求：
curl -I -H "If-Modified-Since: Thu, 20 Aug 2026 14:32:11 GMT" https://your-site.com/static/main.css
若返回 304 Not Modified，说明校验链路完整。
不复杂但容易忽略
