Go语言如何做ETag_Go语言ETag缓存教程【实战】-Golang-PHP中文网

go 的 http.servefile 不自动加 etag，需用 http.servecontent 手动实现；etag 应用弱校验格式 w/"xxx"，推荐构建时预计算内容哈希并嵌入文件名以规避运行时开销。

go语言如何做etag_go语言etag缓存教程【实战】

Go 的 `http.ServeFile` 不会自动加 ETag，得自己动手

Go 标准库的 http.ServeFile 和 http.FileServer 默认不生成或校验 ETag，哪怕文件没变，每次响应都是 200 + 全量 body。这不是 bug，是设计取舍——它追求简单和可预测，不隐式引入基于文件 mtime 或哈希的缓存逻辑。

如果你需要强校验（比如部署后文件内容不变但 mtime 变了，仍希望复用缓存），就得绕过默认逻辑，自己算 ETag 并处理 If-None-Match。

常见错误现象：curl -I http://localhost:8080/app.js 返回 200，且无 ETag 头；加 -H "If-None-Match: xxx" 后仍返回 200 而非 304
适用场景：静态资源托管（JS/CSS/图片）、CDN 回源兜底、API 响应体内容稳定时的客户端缓存优化
别依赖 os.FileInfo.ModTime() 单独做 ETag —— 容器重建、NFS、Git checkout 都可能导致 mtime 变但内容未变

用 `http.ServeContent` 手动控制 ETag 和 304 流程

http.ServeContent 是标准库里唯一支持完整条件响应（包括 ETag、If-Modified-Since、If-None-Match）的函数，但它不接受路径字符串，而是要求你提供 io.ReadSeeker、长度和修改时间 —— 这意味着你要自己打开文件、读取内容（或哈希）、决定怎么生成 ETag。

关键点在于：ETag 值必须带引号，且建议用弱校验（W/"xxx"）避免严格字节比对失败（比如 gzip 压缩差异）。

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本官方下载，版本号 1.26.0，适合旧项目维护、兼容性测试和指定版本开发环境搭建。

下载

示例核心逻辑：

func serveWithETag(w http.ResponseWriter, r *http.Request, path string) {
    f, err := os.Open(path)
    if err != nil {
        http.Error(w, err.Error(), http.StatusNotFound)
        return
    }
    defer f.Close()

    fi, _ := f.Stat()
    etag := fmt.Sprintf(`W/"%x"`, md5.Sum([]byte(fi.Name()+strconv.FormatInt(fi.Size(), 10)+fi.ModTime().String())))

    w.Header().Set("ETag", etag)
    http.ServeContent(w, r, fi.Name(), fi.ModTime(), f)
}

注意：http.ServeContent 内部会检查 ETag 和 If-None-Match，匹配则写 304 并返回；不匹配才继续读取并写 200
性能影响：每次请求都打开文件、stat、算哈希？别这么干。生产环境应预计算 ETag（构建时注入、内存缓存、或用文件 inode+size+mtime 组合）

用 `http.FileSystem` 封装自定义 ETag 逻辑（适合整个静态目录）

如果要给整个 ./static 目录下的所有文件统一加 ETag，直接改每个 http.ServeFile 调用不现实。更合理的方式是实现 http.FileSystem 接口，重写 Open 方法，在返回 http.File 前注入 ETag 逻辑。

标准 http.Dir 返回的 http.File 不暴露底层 os.File，所以你需要包装一层：实现自己的 etagFile 类型，满足 http.File 接口，并在 Stat() 里塞入带 ETag 的 os.FileInfo。

容易踩的坑：http.FileServer 会调用 file.Stat() 获取大小和时间，但不会读取内容 —— 所以 ETag 若依赖内容哈希，必须在 Open 阶段预读或异步缓存，不能等到 Stat() 时才算
兼容性注意：某些代理或 CDN 对弱 ETag（W/"..."）支持更好；强 ETag（"..."）要求字节级一致，gzip 压缩后可能失效
不要在 etagFile.Readdir() 里算 ETag —— 目录列表响应不需要 ETag，且会拖慢索引页加载

ETag 值该用内容哈希还是 mtime+size？

答案取决于你的部署流程和一致性要求。mtime+size 快但不可靠；内容哈希准但有开销。没有银弹，只有权衡。

推荐组合策略：构建时生成 content hash（如 sha256(file)），写进文件名（app.a1b2c3.js），此时 ETag 可退化为固定值（如 "a1b2c3"）甚至不用 —— URL 本身已带版本
若必须用 ETag：优先用 W/"size-mtime-hashprefix"，例如 W/"12345-1712345678-abcd1234"，前两段快速判断，第三段防哈希碰撞
绝对避免：ETag: "mtime" 这种纯时间戳 —— 秒级精度不够，且跨服务器时钟不同步会导致缓存错乱
调试技巧：curl -v -H "If-None-Match: W/\"xyz\"" http://localhost:8080/test.txt 看是否返回 304；用 http.DetectContentType 检查是否误判 MIME 类型导致浏览器不缓存