etag优先级更高是因为http/1.1规范（rfc 7232）明确规定：当请求同时携带if-none-match和if-modified-since时，服务器必须先校验etag；etag是强校验器，基于内容摘要，精度高且不受时间戳偏差影响，而last-modified仅为弱校验器，仅依赖秒级时间戳。
当服务器同时提供了 Last-Modified 和 ETag，而客户端在请求中同时携带了 If-Modified-Since 和 If-None-Match 两个条件头时，服务器会优先校验 ETag。
为什么 ETag 优先级更高
HTTP 协议明确规定：若请求中同时存在 If-None-Match 和 If-Modified-Since，服务端必须先验证 ETag。只有当 ETag 不匹配（即未命中）时，才继续检查 Last-Modified —— 但实际中绝大多数主流服务器（如 Nginx、Apache、Express）在 ETag 校验失败后，不会 fallback 到 Last-Modified 校验，而是直接返回 200 响应体。
- ETag 是内容摘要，精度高，能准确反映资源是否真正变化
- Last-Modified 仅依赖文件系统时间戳，存在秒级精度不足、时钟偏差、批量覆盖重置等问题
- HTTP/1.1 规范（RFC 7232）将 ETag 定义为“强校验器”，Last-Modified 是“弱校验器”，语义上就赋予前者更高权威性
客户端发什么头，决定服务器校验什么
服务器不会“自动选一个”，而是严格按客户端携带的请求头来响应：
- 只带 If-None-Match → 只比对 ETag，忽略 Last-Modified
- 只带 If-Modified-Since → 只比对 Last-Modified，忽略 ETag
- 两个都带 → 先比 ETag；ETag 匹配则直接返回 304；不匹配通常不再查时间戳，直接返回 200 + 新内容
配置建议：避免冗余，明确意图
不必强行同时开启两者。选择依据是资源特性：
- 静态构建产物（如 Webpack 输出的 app.a1b2c3.js）→ 用内容哈希 ETag，禁用或忽略 Last-Modified
- 普通托管文件（图片、字体）→ 用 Last-Modified 足够，省去 ETag 计算开销
- 若必须共存（如 Nginx 默认发 Last-Modified + etag on），确保 ETag 生成逻辑稳定，且不与后端时间戳冲突
注意：优先级不是“谁更早配置”，而是协议层硬性约定
这个优先关系与 Cache-Control、Expires 等无关，也不受前端 HTML 或 JS 影响——它完全由 HTTP 请求头组合和服务端实现决定。浏览器自动发送对应条件头，服务端按规范响应，中间任何环节（CDN、反向代理）都不能擅自修改或跳过该逻辑。
