协商缓存本质是验证缓存有效性，而非决定是否使用缓存；Last-Modified基于秒级时间戳，精度低但开销小，ETag基于内容哈希，精度高但计算成本大；两者共存时优先校验ETag，不匹配再 fallback 到 Last-Modified。
协商缓存不是“要不要用缓存”，而是“这个缓存还能不能用”。Last-Modified 和 ETag 都是服务器给浏览器的“资源身份证”，但它们的生成逻辑、精度、适用场景和潜在问题完全不同。
Last-Modified：基于时间戳的粗粒度标记
服务器在首次响应中返回 Last-Modified: Fri, 15 Feb 2026 03:06:18 GMT，表示该资源**最后修改时间精确到秒**。浏览器下次请求时自动带上 If-Modified-Since，值就是这个时间戳。
- 服务器比对：只看文件系统里这个时间之后有没有变动，不关心内容是否真变了
- 问题明显：1 秒内改了两次，时间戳可能不变；文件定期重生成但内容没变，时间戳却更新，导致缓存失效
- 依赖服务器时钟准确，分布式部署时若各节点时间不同步，结果不可靠
- 开销小，只需读取文件元信息，适合静态资源量大、更新不频繁的场景
ETag：基于内容哈希的细粒度指纹
服务器为资源计算一个唯一标识，比如 ETag: "abc123"（实际常为 W/"hash" 格式），本质是内容的摘要（如 MD5、CRC 或组合 inode + size + mtime）。浏览器后续请求携带 If-None-Match: "abc123"。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 服务器比对：重新计算当前资源的哈希，严格匹配内容是否一致
- 精度高：毫秒级变更、空格增删、编码微调都能被识别
- 注意陷阱：分布式环境默认关闭 ETag，因为不同机器生成的哈希可能不一致；若必须启用，需统一算法和输入源
- 开销略大：每次需读取并计算文件内容，对大文件或高并发有压力
优先级与协作机制
两者不是二选一，而是有明确优先级和 fallback 关系：
立即学习“Java免费学习笔记（深入）”；
- 服务器优先检查 If-None-Match（对应 ETag），匹配成功直接返回 304
- 若响应头没带 ETag，才退而检查 If-Modified-Since（对应 Last-Modified）
- 实际项目中常同时返回两个字段，既保精度又留兜底，但需避免 ETag 生成不稳定引发误判
怎么选？看你的资源特点
静态构建产物（如 Webpack 输出的 JS/CSS 文件）建议用 ETag —— 内容不变则哈希不变，缓存利用率高；高频写入的日志页、时间戳水印页等，用 Last-Modified 更轻量稳妥。生产环境若用 Nginx 或 CDN，注意确认其 ETag 行为是否默认开启及是否适配集群。
