nginx中if_modified_since指令用于优化协商缓存，支持exact（严格相等）、before（服务端修改时间≤客户端时间则返回304）和off（忽略请求头、始终返回200）三种模式，配合expires modified可实现文件不变时全程本地缓存、一改即更新的智能缓存效果。
在 Nginx 中配置 if_modified_since 指令，核心目标是让浏览器在重复请求静态资源时，能根据文件真实修改时间智能返回 304 Not Modified，而不是无条件重传。它不改变文件内容，只优化协商缓存的判断逻辑。
理解 if_modified_since 的三种行为模式
该指令控制 Nginx 如何比对响应头中的 Last-Modified 与客户端请求头里的 If-Modified-Since：
- exact（默认）：严格时间相等才返回 304。只要服务端文件修改时间与客户端携带的时间毫秒级不一致，就返回 200 —— 最保守、最常见，适合大多数场景。
-
before：只要服务端文件的最后修改时间 ≤ 客户端的
If-Modified-Since值，就返回 304。更宽松，适合希望延长缓存命中率、且能接受“略旧但未变”判定的场景。 -
off：完全忽略客户端发来的
If-Modified-Since请求头，始终返回 200 和完整资源 —— 等价于禁用协商缓存，一般仅用于调试或特殊兜底策略。
在 location 块中正确启用并调优
无需额外模块（Nginx 1.7.34+ 默认内置），直接在对应静态资源路径下配置即可：
location /assets/ {
root /var/www/app;
expires modified 7d; # 主动缓存 + 关联文件修改时间
if_modified_since before; # 启用宽松比对
etag on; # 保持 ETag 协商（默认已开）
}
注意点：
- 不需要手动添加
Last-Modified头，Nginx 会自动基于文件系统mtime生成； - 避免写
add_header Last-Modified ""，除非你明确要清除上游注入的错误值； - 若使用容器或只读挂载，
mtime可能不可靠，此时before或exact都可能失效，建议配合ETag或构建时注入版本哈希。
验证是否生效的关键检查项
打开浏览器开发者工具 → Network 标签页，观察一个静态资源的两次请求：
- 首次请求：响应头应含
Last-Modified和ETag，状态码为200； - 刷新后请求：请求头应带
If-Modified-Since和If-None-Match，若配置正确且文件未改，响应应为304，且响应体为空； - 手动 touch 修改文件后再刷新：应看到新
Last-Modified值，并返回200+ 新内容。
搭配 expires modified 提升时效性
expires modified 365d 不是设固定过期时间，而是将缓存有效期动态锚定到文件修改时刻之后一年。它和 if_modified_since 是互补关系：
-
expires modified决定浏览器是否发起条件请求（即是否带If-Modified-Since）； -
if_modified_since决定收到条件请求后，Nginx 怎么比对并返回 304 还是 200。
两者合用，才能实现「文件不变则全程走本地缓存，一改即立刻更新」的效果。
