contentlength 在 gin 中总是 -1 是因默认响应写入不缓冲，无法预知长度；需通过自定义 responsewriter 包装器在 write/writestring/writeheader 中实时计数，且须置于 gzip 中间件之后以统计原始字节数。
为什么 ContentLength 在 Gin 中总是 -1？
因为 Gin 默认使用 http.ResponseWriter 的包装器（responseWriter），它在写入前不缓冲响应体，ContentLength 无法提前得知。调用 w.Header().Get("Content-Length") 或 w.ContentLength 基本都返回 -1，这不是 bug，是流式写入的正常表现。
要精确统计 JSON 字节大小，必须拦截实际写出的字节流——要么自己实现 http.ResponseWriter 包装器并计数，要么改用缓冲写入再读取长度。
用 ResponseWriter 包装器实时计数（推荐）
这是最可靠的方式：在 Write() 和 WriteHeader() 调用时累加字节数，兼容所有返回方式（c.JSON()、c.Data()、c.String() 等），且不影响性能或 HTTP 流程。
关键点：
- 必须在
WriteHeader()后才开始计Write()的字节数（避免响应头被重复计算） - 需覆盖
Write()、WriteString()、WriteHeader()三个方法 - 不能依赖
Flush()或Hijack()，Gin 不保证它们被调用
示例中间件：
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
type sizeWriter struct {
http.ResponseWriter
size int
wroteHeader bool
}
func (w *sizeWriter) Write(b []byte) (int, error) {
if !w.wroteHeader {
w.WriteHeader(http.StatusOK)
}
n, err := w.ResponseWriter.Write(b)
w.size += n
return n, err
}
func (w *sizeWriter) WriteString(s string) (int, error) {
if !w.wroteHeader {
w.WriteHeader(http.StatusOK)
}
n, err := w.ResponseWriter.WriteString(s)
w.size += n
return n, err
}
func (w *sizeWriter) WriteHeader(statusCode int) {
w.ResponseWriter.WriteHeader(statusCode)
w.wroteHeader = true
}
func SizeMiddleware() gin.HandlerFunc {
return func(c *gin.Context) {
sw := &sizeWriter{ResponseWriter: c.Writer}
c.Writer = sw
c.Next()
log.Printf("path=%s status=%d size=%d bytes", c.Request.URL.Path, c.Writer.Status(), sw.size)
}
}
注意 c.Render() 和模板渲染的特殊性
Gin 的 c.JSON()、c.XML() 底层都走 c.Render()，而 Render 会先写状态码和 Header，再调用 Write() 输出序列化内容。上述包装器能正确捕获全部字节，但如果你手动调用 c.Render() 并传入自定义 render.Render 实现，要确保它不绕过 Write() 直接操作底层 ResponseWriter——否则字节数会漏计。
常见陷阱：
- 使用
c.Data(200, "application/json", []byte{...})是安全的（走Write()） - 但直接调用
c.Writer.Write(...)会绕过包装器的计数逻辑，应避免 - 第三方 render 插件（如
gin-contrib/multitemplate）若内部调用io.Copy到原始ResponseWriter，也会漏计
别用 bytes.Buffer 全局缓存响应体
有人尝试用 bytes.Buffer 完全接管响应写入，等请求结束再把 buffer 内容 copy 给真实 writer 并取 Len()。这看似简单，但会导致两个严重问题：
- HTTP 流式响应失效：客户端无法分块接收，长响应卡顿明显
- 内存压力陡增：大文件下载或大数据集 JSON 可能吃光内存
除非你明确要求“只统计、不流式”，否则不要这么做。真实业务中，流式 + 精确字节数二者可兼得，靠的是包装器，不是缓冲。
真正难处理的是 gzip 压缩场景——Content-Length 是压缩后长度，但多数人想统计的是原始 JSON 字节数。如果启用了 gzip.Gzip() 中间件，记得计数包装器必须套在 gzip writer 之后（即更靠近最终 responseWriter），否则你统计到的是压缩后的字节数。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
