gin.timeout 不适合移动端弱网，因其硬中断式超时会直接返回504，无法支持柔性降级；应改用 time.afterfunc + context 标志实现业务可控的超时分支与差异化降级策略。
为什么默认的 gin.Timeout 不适合移动端弱网
因为 gin.Timeout 是硬中断式超时：一旦超过设定时间，直接返回 504 或自定义错误，不给业务任何降级机会。而弱网下用户更需要“能返回就返回，哪怕数据少一点”——比如列表接口只返回前 10 条、详情页跳过非关键字段、图片 URL 替换为占位图等。这种柔性响应必须在超时发生前由业务逻辑主动介入，而不是等框架强制 kill goroutine。
用 c.AbortWithStatusJSON + 自定义上下文控制超时分支
核心思路是：不依赖 gin.Timeout，改用 time.AfterFunc 启动异步超时监听，在业务 handler 内部做超时判断和降级分支。关键点在于用 c.Get("timeout_triggered") 和 c.Set("timeout_triggered", true) 在 goroutine 间安全通信（gin.Context 是 request-scoped 的，线程安全）。
常见错误现象：panic: concurrent write to response body —— 多个 goroutine 同时调用 c.JSON()。
实操建议：
- 在 handler 开头立即调用
c.Set("start_time", time.Now())记录起点 - 启动
time.AfterFunc(8 * time.Second, func() { ... })，内部检查c.IsAborted() == false再执行c.AbortWithStatusJSON(200, fallbackData) - 业务逻辑末尾加
if !c.IsAborted() { c.JSON(200, normalData) }，确保仅未超时才走主路径 - 避免在超时回调里访问数据库或调用外部 HTTP，否则可能引发二次超时
移动端需区分网络类型设置不同超时阈值
单纯设一个全局 8s 超时不够智能。真实场景中，4G/5G 下可接受 3–5s，而弱 2G/高丢包 Wi-Fi 下应放宽到 10–15s，并配合更激进的降级策略（如禁用分页、关闭图片懒加载、返回缓存快照）。
实现方式依赖客户端传参或 UA 特征识别：
- 前端在请求 header 中带
X-Network-Type: 4g或X-Rtt-Ms: 420 - 服务端用
c.Request.Header.Get("X-Network-Type")动态计算超时时间，例如：baseTimeout := 5 * time.Second; if netType == "2g" { baseTimeout = 12 * time.Second } - 不要依赖 User-Agent 字符串解析网络类型，准确率低且易被伪造；优先使用客户端主动上报的 RTT 或信号强度指标
降级数据必须与主逻辑共享同一份结构体定义
否则容易出现字段不一致、JSON 序列化 panic、前端解构失败等问题。比如主接口返回 type UserResp struct { Name string `json:"name"` Avatar string `json:"avatar"` Bio string `json:"bio,omitempty"` }，降级时不能临时拼 map，而应复用该 struct，仅置空或填默认值。
容易踩的坑：
- 降级时返回
map[string]interface{}，导致字段名大小写不一致（如"avatar"vs"Avatar"） - 忘记给 struct 字段加
json:tag，降级后字段消失 - 在降级路径中调用未初始化的指针字段（如
user.Profile为 nil），触发 panic - 使用
json.RawMessage做动态字段填充，但没处理空值边界，导致前端解析出 null 而不是 {}
复杂点在于：超时判断和降级响应必须在同一个 request context 生命周期内完成，不能跨 goroutine 修改 gin.Context 的状态以外的数据。一旦 c.Abort() 被调用，后续所有 c.JSON() 都会被忽略——这点很容易被忽略。
