1. HTTP缓存机制与ETag基础想象一下你每天都要去超市买牛奶。如果每次都要打开冰箱确认是否喝完效率就太低了。聪明的做法是在门口贴张便签记录剩余量。ETag就像这张便签是服务器给资源贴的指纹标签。ETag的本质是服务器生成的唯一标识字符串通常通过资源内容的哈希值或版本号生成。比如一个文章API可能返回这样的响应头HTTP/1.1 200 OK ETag: a3f5-58c3b7e5 Content-Type: application/json当客户端首次请求时服务器会返回资源内容如JSON数据ETag值相当于资源版本号缓存策略如Cache-Control关键特性强ETag要求字节完全匹配如a3f5弱ETag前缀带W/表示内容语义相同即可如W/a3f5必须用双引号包裹这是HTTP规范要求我在实际项目中遇到过ETag格式错误导致缓存失效的情况。某次用Spring Boot时忘记加引号结果Chrome直接忽略了缓存验证每次都会重新下载资源。2. If-None-Match的缓存验证机制当客户端再次请求相同资源时会把之前收到的ETag通过If-None-Match头回传给服务器GET /articles/123 HTTP/1.1 If-None-Match: a3f5-58c3b7e5这时服务器会比较当前ETag与客户端传来的值匹配返回304 Not Modified空响应体不匹配返回200 OK和新资源性能优势减少网络传输304响应平均比完整资源小80%降低服务器压力省去重复渲染的开销提升用户体验资源加载更快实测数据某CMS系统引入ETag后API吞吐量从1200 QPS提升到2100 QPS同时带宽消耗降低62%。3. If-Match的乐观锁实现在多人编辑场景中If-Match能有效防止更新丢失。假设两个编辑同时修改文章编辑A获取文章得到ETag: v1编辑B获取文章得到ETag: v1编辑A提交修改带If-Match: v1成功更新为v2编辑B提交修改带If-Match: v1服务器返回412 Precondition FailedSpring Boot实现示例PatchMapping(/articles/{id}) public ResponseEntity? updateArticle( PathVariable String id, RequestHeader(If-Match) String clientETag, RequestBody ArticleUpdate update) { String currentETag articleService.getCurrentETag(id); if(!currentETag.equals(clientETag)) { return ResponseEntity.status(412).build(); } Article updated articleService.update(id, update); return ResponseEntity.ok() .eTag(updated.getETag()) .body(updated); }常见误区混淆If-Match和If-None-Match的使用场景没有正确处理带W/的弱ETag比较忽略412错误的客户端处理逻辑4. 实战中的陷阱与解决方案陷阱1集群环境下的ETag生成在分布式系统中不同节点可能生成不一致的ETag。我们曾遇到用户看到内容闪烁的问题原因是节点A用MD5生成ETag节点B用修改时间戳生成ETag解决方案# 使用一致的生成算法如资源属性版本号 def generate_etag(article): return hashlib.md5( f{article.id}-{article.version}-{article.updated_at.timestamp()}.encode() ).hexdigest()陷阱2弱比较算法误用弱ETagW/xxx比较时服务器可能认为这两个值等效If-None-Match: W/123 ETag: W/456最佳实践关键资源使用强ETag大文件等可使用弱ETag明确文档说明比较规则性能优化技巧对静态资源启用ETag对动态API按需启用结合Cache-Control的max-age使用Nginx配置示例location ~* \.(js|css|png)$ { etag on; expires 7d; add_header Cache-Control public, max-age604800; }5. 高级应用场景场景1断点续传结合If-Range和ETag实现文件分块传输GET /large-file.zip HTTP/1.1 Range: bytes1000-2000 If-Range: a3f5-58c3b7e5场景2API版本协商客户端可携带多个ETagGET /data HTTP/1.1 If-None-Match: v2, v1场景3分布式缓存验证Redis存储ETag的架构app.get(/product/{id}) async def get_product(id: str, request: Request): redis_key fproduct:{id}:etag current_etag await redis.get(redis_key) if_none_match request.headers.get(if-none-match) if if_none_match current_etag: return Response(status_code304) product await db.get_product(id) new_etag generate_etag(product) await redis.setex(redis_key, 3600, new_etag) return JSONResponse( contentproduct.dict(), headers{ETag: new_etag} )6. 性能监控与调试监控指标建议304响应占比理想60%ETag生成耗时应5ms缓存命中率Chrome开发者工具技巧网络标签查看ETag和If-None-Match使用Disable cache选项强制刷新检查Size列的(from disk cache)提示常见问题排查如果看到304但仍有网络传输检查响应头是否包含Body如果缓存不生效确认Vary头配置正确如果ETag频繁变化检查生成算法是否过于敏感某次性能调优中我们发现ETag生成用了完整内容MD5导致CPU飙升。改为最后修改时间ID的组合后系统负载下降40%。7. 最佳实践总结该用ETag的场景需要精确控制缓存验证资源频繁小幅修改需要实现乐观锁不该用ETag的场景静态资源已有长期缓存策略资源永远不缓存如私密数据性能敏感且版本控制简单的场景决策流程图是否需要缓存? → 否 → 禁用缓存 ↓是 能否接受弱一致性? → 是 → 使用Last-Modified ↓否 是否需要原子更新? → 是 → 强ETag If-Match ↓否 使用弱ETag If-None-Match在大型CMS系统中我们最终采用的混合策略文章内容用强ETag实现编辑锁评论列表用弱ETag加速加载静态资源直接用长期缓存。这套方案经受住了百万级日活的考验服务器负载始终保持在安全水位线下。