Gin 不处理前端自适应逻辑，仅根据 User-Agent、Accept 头或显式参数决定返回 HTML、JSON 或不同结构 JSON；推荐用 uap-go 解析 UA，复用 handler 实现内容协商，按终端定义不同结构体做字段裁剪，静态资源按终端分目录托管。
Gin 本身不处理前端自适应逻辑，它只负责把后端数据按需返回给前端——所谓“自适应网页适配接口”，本质是后端根据请求特征（如 User-Agent、Accept 头、或显式传参）决定返回 HTML 页面、JSON 数据，还是不同结构的 JSON（比如移动端精简字段）。关键不在 Gin 多神奇，而在你怎么判断、怎么分发、怎么避免踩坑。
如何用 Gin 判断请求来源是 PC 还是移动设备
别依赖 JavaScript 或 CSS 媒体查询做后端适配——那是前端的事。后端唯一可靠依据是 HTTP 请求头里的 User-Agent 字符串。
-
c.GetHeader("User-Agent")获取原始 UA，但直接字符串匹配易漏判（比如新出的折叠屏 UA、微信内置浏览器变种） - 推荐用轻量库
github.com/ua-parser/uap-go解析，它维护了最新 UA 规则库，能准确识别IsMobile/IsTablet - 注意：某些 CDN 或反向代理（如 Nginx）会默认过滤或改写
User-Agent，上线前务必用curl -H "User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)..." http://your-api/实测
同一个路由返回 HTML 还是 JSON 怎么设计
最常见错误是硬编码两个 endpoint（/api/user 和 /user），结果维护两套逻辑。正确做法是复用 handler，靠内容协商决定响应格式。
- 检查
c.Negotiate支持的 MIME 类型：c.Negotiate(200, gin.H{"name": "alice"}, "text/html", "application/json") - 更可控的方式是显式读取
Accept头：accept := c.GetHeader("Accept")，然后用strings.Contains(accept, "text/html")或正则匹配 - 若前端明确传参（如
?format=html），优先以参数为准，避免被浏览器默认 Accept 干扰 - 返回 HTML 时必须调用
c.HTML()，且模板路径要和r.LoadHTMLGlob("templates/**/*")加载范围一致；返回 JSON 用c.JSON()，别混用
移动端接口字段裁剪要不要在 handler 里写 if-else
不要。字段裁剪是数据层职责，不是路由层该干的事。硬编码 if isMobile { user.Name = "" } 会导致业务逻辑散落、难以测试、后续加平板适配时再补一堆分支。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 定义两个结构体：
type UserMobile struct { Name string `json:"name"` }和type UserDesktop struct { Name, Email, Avatar string `json:"name","email","avatar"` } - 用
c.ShouldBindJSON(&v)绑定时，字段校验规则（如binding:"required"）可按终端类型分别定义 - 数据库查出原始数据后，统一用
mapstructure.Decode或手动赋值转成对应结构体，保持 handler 干净 - 特别注意：字段名大小写和
json:tag 必须严格匹配，漏一个 tag 就导致移动端收不到字段
Gin 的静态文件服务对自适应页面有没有影响
有，而且容易被忽略。Gin 默认的 r.Static("/static", "./static") 对所有客户端一视同仁，但实际中 PC 和移动站可能用不同版本的 JS/CSS（比如移动端用压缩版、PC 用带 sourcemap 的开发版）。
- 不要把 PC 和 mobile 资源混放同一目录，否则缓存策略冲突（CDN 缓存 PC 版 JS，移动端却加载了）
- 建议按终端分目录：
./static/pc/和./static/mobile/，再用中间件动态选择路径：c.Request.URL.Path = strings.Replace(c.Request.URL.Path, "/static/", "/static/"+device+"/", 1) - 更稳妥的是让前端构建时生成带哈希的文件名（
app.mobile.a1b2c3.js），后端只管托管，由构建流程控制资源分发
真正难的不是写几个 if isMobile，而是让字段裁剪、模板选择、静态资源路径这些决策点清晰分离，不耦合在路由 handler 里。一旦开始在 c.Param() 后面接一长串三元表达式，就说明架构该调整了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
