应通过user-agent字符串匹配识别设备类型，组合判断“mobile”“android”等标识并排除桌面特征；结构体用指针字段+omitempty标签动态控制json序列化；统一响应结构体封装设备专属payload，避免多路c.json()；移动端优先裁剪大体积字段而非小字段。
如何识别设备类型并分支处理
Gin 本身不提供设备检测能力，必须依赖 User-Agent 请求头手动解析。不要用第三方 UA 解析库（如 uap-go）做全量解析——多数场景只需区分移动端和桌面端，简单字符串匹配更轻量、更可控。
- 检查
c.Request.Header.Get("User-Agent")是否包含"Mobile"或常见移动标识（如"Android"、"iPhone"、"iPad"），注意大小写不敏感 - 避免只匹配
"Mobile"：部分桌面浏览器（如 Chrome DevTools 模拟器）也会带该词，建议组合判断，例如同时不含"Chrome/[^ ]+ Desktop" - 若需精确识别微信内置浏览器，额外检查是否含
"MicroMessenger"且不含"WindowsWechat"
结构体字段按设备动态裁剪
Go 的 encoding/json 不支持运行时动态字段开关，硬编码两套结构体或用 map[string]interface{} 易失控。推荐在结构体中保留所有字段，但通过 json 标签控制序列化行为。
- 为需差异化返回的字段添加条件标签，例如：
Detail string `json:"detail,omitempty"`（桌面端保留，移动端 omit） - 用指针字段 + 零值判断实现逻辑裁剪：
Thumbnail *string `json:"thumbnail,omitempty"`，移动端设为nil，桌面端赋值 - 避免在
c.JSON()前做delete()操作 map —— 并发不安全，且破坏结构体语义
响应前统一组装而非多路 c.JSON()
不要写成 if mobile { c.JSON(...); return } else { c.JSON(...) }。分支多了难维护，且容易漏掉公共字段（如 code、msg）的一致性校验。
- 定义统一响应结构体，如
Response，其Data字段类型为any - 先构造设备专属的 payload（如
mobilePayload或desktopPayload），再统一塞进Response{Data: payload} - 这样能确保 HTTP 状态码、错误包装、中间件日志等逻辑完全复用，避免重复调用
c.JSON()导致 header 冲突
移动端 JSON 体积优化的实际取舍
“为移动端精简字段”不是无脑删，得看字段实际开销。JSON 序列化本身极快，瓶颈往往在传输和前端解析。
- 优先裁剪大体积字段：如富文本 HTML 字段、base64 图片、长数组（
comments限制为前 3 条） - 慎删小字段：像
created_at（string，通常 20 字符）或status（enum，2–5 字符）删了省不了多少，反而增加前后端理解成本 - 真正有效的压缩是改字段类型：比如把时间戳从
"2026-08-11T14:09:00Z"改为1752271740（int64），配合前端约定解析
json 标签拼写错误、User-Agent 解析逻辑放在 handler 外层还是中间件里——这些细节不写进结构体定义或响应组装流程，就永远在 debug 时多绕三圈。
