协商缓存中，服务端通过fs.statsync获取文件mtime并调用toutcstring()设last-modified头，浏览器自动带if-modified-since头，服务端需严格字符串比对决定返回304或200，注意秒级精度、字符串全等及中间件干扰。
JavaScript 中设置协商缓存的 Last-Modified 与 If-Modified-Since，核心是服务端在响应中写入 Last-Modified 响应头，浏览器后续请求自动带上 If-Modified-Since 请求头，服务端比对后决定返回 304 还是 200。
服务端设置 Last-Modified（Node.js 示例）
以 Node.js 原生 HTTP 服务为例，读取静态文件时需获取其最后修改时间，并转为标准 UTC 字符串格式：
Java Linux版
下载
Java Linux版下载入口，提供 Oracle JDK 26.0.2 官方 Linux 安装包、Java 环境配置、JDBC 数据库连接和 Java 服务端开发相关信息。
- 用
fs.statSync获取文件元信息，提取mtime（修改时间） - 调用
.toUTCString()转成 HTTP 兼容格式（如Wed, 18 Dec 2013 00:32:38 GMT） - 通过
res.setHeader('Last-Modified', mtime.toUTCString())写入响应头 - 同时建议设置
Cache-Control: no-cache，明确跳过强缓存，强制进入协商流程
服务端处理 If-Modified-Since 请求
浏览器第二次访问时会自动携带 If-Modified-Since 头，服务端需做精确字符串比对：
- 从
req.headers['if-modified-since']取值（注意小写、带连字符） - 比对它是否严格等于当前文件的
mtime.toUTCString() - 相等 → 返回状态码
304 Not Modified，且不发送响应体，res.end()即可 - 不等 → 正常返回
200，附上新的Last-Modified和资源内容
注意事项与常见坑点
这个机制看着简单，但实际容易出错：
-
Last-Modified精度只有秒级，若文件 1 秒内多次改动，可能漏判更新 - 比对必须是完整字符串相等，不能用
new Date()解析后再比毫秒数——时区/格式化差异会导致失败 - 某些构建工具（如 Webpack Dev Server）默认不设此头，需手动配置中间件补充
- CDN 或反向代理可能覆盖或删除
Last-Modified，需检查中间层行为
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
