nginx对静态资源的last-modified时间戳默认自动基于文件mtime生成，无需手动设置；需确认未被last_modified off等指令关闭，并通过curl验证响应头存在且格式符合rfc 1123。
Nginx 对静态资源的 Last-Modified 时间戳是自动设置的，不需要手动计算或拼接时间字符串。它的值直接来源于文件系统中该文件的 mtime（最后修改时间），且默认就启用——你真正要做的，是确认它没被意外关闭，并理解它如何参与协商缓存。
Last-Modified 是怎么生成的
- Nginx 在处理
.js、.css、.png等静态文件时，只要启用了sendfile或常规文件读取流程，就会自动读取文件的mtime，并以 RFC 1123 格式（如Wed, 21 Oct 2025 07:28:00 GMT）写入响应头Last-Modified。 - 这个行为由
last_modified指令控制，默认值就是on，所以绝大多数配置下它已生效。 - 不需要
add_header Last-Modified ...手动设置，否则可能覆盖真实时间或引发格式错误。
如何确认和保障它正常工作
- ✅ 检查是否被显式关闭：在
server或location块中搜索last_modified off;，如有则删掉或改为last_modified on;。 - ✅ 验证响应头是否存在：用
curl -I https://yoursite.com/static/app.js查看输出里是否有Last-Modified行。 - ✅ 注意文件挂载方式：如果静态文件放在只读文件系统（如某些容器镜像或 NFS 只读挂载），
mtime可能恒定不变，导致Last-Modified失效——此时应改用ETag或构建时注入哈希版本号。 - ✅ 时间精度注意：
Last-Modified只精确到秒，同一秒内多次更新无法区分；若需更高精度（比如 CI/CD 构建产物秒级发布），建议配合ETag或强制使用内容哈希命名。
它怎么参与缓存验证
- 浏览器下次请求时带上
If-Modified-Since:，Nginx 默认用if_modified_since exact;（精确匹配）比对。 - 若文件
mtime未变，返回304 Not Modified；变了则返回200和新内容。 - 无需额外配置
if_modified_since，因为exact是默认行为；只有在特殊需求下（如允许“早于等于”也返回 304）才需显式写if_modified_since before;。
不复杂但容易忽略。
