直接调用 c.getheader("user-agent") 即可获取原始字符串，gin 不解析仅透传；推荐用 uap-parser/uap-go 解析设备类型，全局复用 parser 实例，将 device.class 等关键字段存入 c.set() 供下游使用。
怎么从 Gin 的 *gin.Context 里拿到 User-Agent 字符串
直接调用 c.GetHeader("User-Agent") 就行，Gin 不会自动解析它，只负责透传原始 HTTP 头。注意大小写不敏感，但按惯例写成 User-Agent 最稳妥。
常见错误是误用 c.Request.Header.Get("user-agent") —— 虽然也能工作，但绕过了 Gin 的封装层，且在中间件中若请求头被修改过（比如反向代理加了 X-Forwarded-For 类头），c.Request.Header 可能不是最终值；而 c.GetHeader() 内部做了标准化处理，更可靠。
- 如果前端经过 Nginx 或 Cloudflare，确保它们没删掉或覆盖
User-Agent，检查 Nginx 配置里有没有proxy_set_header User-Agent "";这类清空操作 - 移动端 WebView 或小程序环境常伪造 UA，比如微信内置浏览器固定以
MicroMessenger结尾，不能单靠是否存在就断定是微信 - Gin 默认不校验 header 长度，超长 UA（如某些爬虫带大量参数）可能被截断，实际长度限制取决于 Go 的 http.Server.MaxHeaderBytes，默认是 1MB，一般够用
用什么库解析 User-Agent 判断设备类型
别手写正则匹配，UA 字符串格式混乱且持续变化。推荐用 ua-parser/uap-go，它是官方 UA Parser 的 Go 移植版，规则库定期同步，支持 desktop / mobile / tablet 三级分类。
安装：go get -u github.com/ua-parser/uap-go/uaparser
初始化一次 parser 即可复用（全局或 per-router），不要每次请求都 new：
var parser = uaparser.NewFromSaved()
然后在 handler 里解析：
ua := c.GetHeader("User-Agent")
if ua == "" {
// 没有 UA，按 desktop 处理或返回 400
return
}
userAgent := parser.Parse(ua)
deviceType := userAgent.Device.Family // 如 "iPhone"、"Windows"、"Unknown"
deviceClass := userAgent.Device.Class // "mobile"、"desktop"、"tablet"
-
Device.Class是最稳定的判断依据，比看字符串含 "Mobile" 更准，因为部分桌面浏览器（如 Chrome on Android Desktop mode）UA 里也有 Mobile 字样 -
Device.Family返回厂商/系统名，但小众设备（如 KaiOS 手机、任天堂 Switch 浏览器）可能为"Other"，需结合OS.Family和UA.String()人工 fallback - parser 初始化耗时约 5–10ms（加载 YAML 规则），必须放在 init 或服务启动阶段，不能放 handler 里
为什么有时候 Device.Class == "desktop" 但其实是手机 Safari
这是 UA 字符串本身的问题：iOS 13+ 的 Safari 在桌面模式下会主动声明自己是 Macintosh，且不带 Mobile 字段，导致 parser 判为 desktop。这不是库的 bug，是苹果故意为之。
解决办法不是改 parser，而是加一层业务逻辑兜底：
- 检查
OS.Family == "iOS"且OS.Major == "13"及以上，同时Browser.Family == "Mobile Safari"，这种组合基本可认定是 iOS 移动端 - 更通用的做法：结合
HTTP Accept头（移动端常含application/json）、HTTP Sec-CH-UA-Mobile（Chromium 的客户端 hints，值为?1表示移动设备），但后者需要前端配合发送 - 纯服务端无额外信息时，保守策略是：当
Device.Class == "desktop"但OS.Family == "iOS"或OS.Family == "Android"，默认按 mobile 处理——毕竟真有用户开着 iPad 的桌面模式，但比例极低
Gin 中间件里统一处理 UA 解析要注意什么
把解析结果存到 c.Set() 里供下游 handler 使用，避免重复解析：
c.Set("device_class", userAgent.Device.Class)
c.Set("ua_parsed", &userAgent)
但别存原始 *uaparser.UserAgent 指针——它内部含 sync.Pool 引用，跨 goroutine 传递可能引发 panic。应该存拷贝或只存关键字段。
- 中间件里解析失败（如 UA 为空或 parser panic）要设默认值，比如
c.Set("device_class", "desktop")，否则下游c.MustGet()会 panic - 如果用了 Gin 的
Context.Copy()（比如异步任务中复制 context），c.Keys里的数据不会自动继承，得手动传参或用其他方式共享 - 高并发下 parser.Parse() 是无锁的，但底层用了 sync.Pool，只要 parser 实例是全局复用的，性能没问题；实测 1k QPS 下单核 CPU 占用不到 5%
设备识别这事没有银弹，UA 只是线索之一。真正要区分体验，最好让前端通过 JS 上报 window.innerWidth 或 navigator.maxTouchPoints，服务端只做兜底。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
