如何在 Golang Gin 框架中根据不同的 Accept 头返回相应的格式数据-Golang-PHP中文网

gin 默认不开启内容协商，必须显式调用 c.negotiate() 并完整配置 gin.negotiate 结构体（含 offered mime 列表与 data），否则无论 accept 头如何均 fallback 至默认格式；其不解析质量因子 q=，仅按顺序匹配首个支持类型。

如何在 golang gin 框架中根据不同的 accept 头返回相应的格式数据

Accept 头没被 Gin 正确识别？检查 `gin.Engine` 是否启用了自动协商

Gin 默认不开启内容协商（Content Negotiation），c.Negotiate() 也不会自动读取 Accept 头并匹配格式。必须显式调用 c.Negotiate() 并传入支持的格式列表，否则无论客户端发什么 Accept，都只会走默认分支（比如 JSON）。

常见错误是写了 c.Negotiate(200, gin.Negotiate) 却漏掉 Offer 配置，导致协商失效。

必须在 c.Negotiate() 中通过 gin.Negotiate 结构体明确声明每种格式的 Offer 和对应数据
Offer 的 MIME 类型要严格匹配请求头（如 application/json、text/xml、application/yaml）
若客户端发送 Accept: application/json, text/html，而你只注册了 application/xml，Gin 会 fallback 到第一个 Offer 或报错（取决于配置）

如何支持 JSON / XML / YAML 三种格式？用 `c.Negotiate()` 显式注册 `Offer`

直接写死多个 c.JSON()/c.XML() 分支容易遗漏或逻辑混乱；用 c.Negotiate() 是 Gin 官方推荐方式，但要注意结构体字段命名和类型一致性。

示例：返回用户数据，同时支持三种格式：

c.Negotiate(200, gin.Negotiate{
    OfferJSON:     true,
    OfferXML:      true,
    OfferYAML:     true,
    OfferProtobuf: false,
    Content:       map[string]interface{}{
        "id":   123,
        "name": "alice",
    },
})

注意：OfferJSON 等只是开关，真正决定响应格式的是请求头中的 Accept 值，Gin 内部按优先级匹配。如果客户端发 Accept: application/yaml，即使你把 OfferYAML 设为 false，也不会返回 YAML —— 反之，如果设为 true 但没注册 YAML 渲染器，会 panic。

确保已导入 github.com/gin-gonic/gin（YAML 支持从 v1.9.0+ 内置，旧版本需手动注册 yaml 渲染器）
Content 字段必须是 map[string]interface{} 或 struct，不能是原始类型（如 "hello"）
如果需要自定义 XML 标签，struct 字段得加 xml:"name" tag，否则 c.Negotiate() 生成的 XML 会用默认字段名

自定义格式（如 CSV、HTML）怎么加？用 `c.NegotiateFormat()` + 手动处理

Gin 不内置 CSV 或 HTML 的 Offer 常量，也不能靠 OfferHTML: true 自动生效。必须用 c.NegotiateFormat() 指定 MIME 类型，并自己写序列化逻辑。

Golang Spf13 Viper

Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。

下载

例如支持 Accept: text/csv：

if c.NegotiateFormat("text/csv") == "text/csv" {
    c.Data(200, "text/csv; charset=utf-8", []byte("id,name\n123,alice"))
    return
}

关键点：

c.NegotiateFormat() 返回匹配到的 MIME 类型（如 "text/csv"），没匹配则返回空字符串
必须在 c.Negotiate() 之前调用，否则 c.Negotiate() 会消耗掉 Accept 头解析结果
返回前务必 return，避免后续 c.Negotiate() 或其他响应逻辑重复执行
HTML 场景更常见：用 c.HTML() 单独处理，别塞进 Negotiate —— 因为 HTML 通常带模板，不是纯数据序列化

调试时发现格式总不对？先看 `c.GetHeader("Accept")` 和实际匹配路径

最常踩的坑是：以为客户端发了 Accept: application/xml，但实际抓包发现是 Accept: */* 或 Accept: text/html,application/xhtml+xml —— Gin 对 */* 默认选第一个 Offer（通常是 JSON），而不是按你预期 fallback。

建议在 handler 开头加日志验证：

accept := c.GetHeader("Accept")
log.Printf("Accept header: %q", accept)
fmt.Printf("Negotiated format: %s\n", c.NegotiateFormat("application/json"))

另外注意：

Gin 的匹配逻辑是「从左到右找第一个能 handle 的 Offer」，不是「选权重最高的」
如果同时注册了 OfferJSON 和 OfferXML，而客户端发 Accept: application/xml;q=0.9, application/json;q=0.8，Gin 仍可能选 JSON（因内部未实现 q-weight 解析）
真实项目中，建议限制 Accept 类型范围（如只允许 application/json 和 application/xml），并在不支持时返回 406 Not Acceptable