Go中间件校验JSON内容类型实践

本文深入剖析了 Go Web 开发中一个常见却易被误解的陷阱：为何使用 `http.DetectContentType` 校验 JSON 请求会误判合法 `application/json` 为 `text/plain`，进而导致无辜的 415 错误；文章直击本质——该函数遵循 WHATWG 嗅探规范，不解析 HTTP 头部，而 JSON 字符串本身无签名特征，注定被降级；作者明确指出正确解法是严格遵循 RFC 7231，信任并标准化解析 `Content-Type` 请求头，而非“猜测”内容，并给出了生产就绪的中间件实现与关键避坑指南，助你写出协议合规、稳定可靠的 Go API 中间件。

本文详解 Go Web 中间件中 http.DetectContentType 无法准确识别 application/json 的根本原因，并提供可靠、符合 HTTP 规范的 MIME 类型校验方案，避免因“MIME 检测误判”导致合法 JSON 请求被拒绝。

本文详解 Go Web 中间件中 `http.DetectContentType` 无法准确识别 `application/json` 的根本原因，并提供可靠、符合 HTTP 规范的 MIME 类型校验方案，避免因“MIME 检测误判”导致合法 JSON 请求被拒绝。

在构建 RESTful API 时，常需中间件强制要求 POST/PUT 请求携带 Content-Type: application/json。但若直接使用 http.DetectContentType() 校验请求体内容（如教程中常见写法），极易出现“明明设置了正确的 Header，却始终返回 415 Unsupported Media Type”的问题——这并非代码逻辑错误，而是对 Go 标准库 MIME 检测机制的误解。

根本原因在于：http.DetectContentType() 不解析 HTTP 头部，而是基于请求体前 512 字节的字节模式（byte pattern）进行启发式嗅探，其行为严格遵循 WHATWG MIME Sniffing 规范。该规范明确指出：JSON 数据（如 {"key":"value"}）不匹配任何预定义的二进制或文本签名规则，最终会被降级为 text/plain。源码印证如下（net/http/sniff.go 第 252 行附近）：

// match 函数中无针对 JSON 的 case 分支
// {"..."} 开头的数据会落入 default 分支 → 返回 "text/plain; charset=utf-8"

因此，http.DetectContentType(buf.Bytes()) 对合法 JSON 字符串返回 "text/plain; charset=utf-8" 是完全符合规范的预期行为，而非 Bug。

✅ 正确做法：依据 RFC 7231，媒体类型应由客户端通过 Content-Type 请求头声明，服务端应优先信任并验证该头部，而非“猜测”内容。中间件应直接解析 Header，而非读取并检测 Body：

func EnforceJSON(h httprouter.Handle) httprouter.Handle {
    return func(w http.ResponseWriter, r *http.Request, ps httprouter.Params) {
        // 1. 检查请求体长度（可选）
        if r.ContentLength == 0 {
            http.Error(w, "Request body is required", http.StatusBadRequest)
            return
        }

        // 2. ✅ 正确：从 Header 获取并标准化 Content-Type
        contentType := r.Header.Get("Content-Type")
        if contentType == "" {
            http.Error(w, "Content-Type header is missing", http.StatusUnsupportedMediaType)
            return
        }

        // 3. ✅ 标准化处理：忽略参数（如 charset=utf-8），仅比对主类型
        mediaType, _, err := mime.ParseMediaType(contentType)
        if err != nil {
            http.Error(w, "Invalid Content-Type format", http.StatusUnsupportedMediaType)
            return
        }

        if mediaType != "application/json" {
            http.Error(w, "Content-Type must be application/json", http.StatusUnsupportedMediaType)
            return
        }

        // 4. ✅ 可选：确保 Body 可重复读取（因上面已读取过 Header，Body 尚未消费）
        // （注意：若后续 handler 需多次读取 Body，需用 io.NopCloser 或 bytes.Buffer 重置）
        h(w, r, ps)
    }
}

⚠️ 关键注意事项：

• 不要调用 buf.ReadFrom(req.Body)：这会消耗请求体，导致下游 handler 读取到空数据；Content-Type 校验无需读取 Body。
• 避免硬编码 charset=utf-8：application/json 规范规定其默认字符集即为 UTF-8，且 charset 参数在 JSON 中已被废弃；应使用 mime.ParseMediaType 提取主类型。
• 若需进一步校验 JSON 语法（如防止恶意 payload），应在 handler 内部用 json.NewDecoder(r.Body).Decode(&v) 执行解析，并捕获 json.SyntaxError 等错误，而非在中间件层做内容嗅探。

总结：Web 服务的 MIME 类型校验是协议层面的契约行为，应以 Content-Type 头为准。http.DetectContentType 适用于文件上传等 无可靠 Header 场景，绝不应用于 API 请求的 Content-Type 强制校验。遵循此原则，即可写出健壮、标准兼容的 Go 中间件。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Go中间件校验JSON内容类型实践》文章吧，也可关注golang学习网公众号了解相关技术文章。