#1. 误以为 Gin = Go 后端全套方案
不是。
Gin 解决的是 HTTP 入口组织问题，不是全栈工程所有问题。
#2. 绑定失败后还继续写别的响应
如果你用了 Bind*，它可能已经帮你写了 400。
你后面再写 422、500，就可能出现“头已经写过”的警告。
所以大多数业务场景里，更稳的是：
- 优先
ShouldBind* - 错了自己控制怎么回
#3. 拿 gin.Context 当标准 context.Context 传到底层
错误。
下游 I/O 传播取消
-> 用 c.Request.Context()
Gin 链内共享字段
-> 用 c.Set / c.Get()#4. 在 goroutine 里直接用原始 c
这会埋数据竞争雷。
要么提取你需要的值，要么 c.Copy()。
#5. 忘记配置 TrustedProxies
这会影响 ClientIP() 的可信度，进而影响：
- 审计
- 限流
- 安全控制
#6. 看到“高性能”就以为一定比所有方案都更快
别把“框架 benchmark”当真实业务吞吐。
你真实系统的瓶颈常常在：
- 数据库
- JSON 编解码
- 网络 I/O
- 外部服务
- 中间件堆叠
- 日志量
Gin 很快，但它不是魔法增压器。
#7. 把所有业务都写在中间件里
中间件是检查站，不是办案大厅。
别让每个请求都绕一圈不必要的全局逻辑。
#8. 把 Gin 当成“只能做 JSON API”
Gin 也能：
- 服务端模板渲染
- 静态文件
- 文件上传下载
- 各种内容格式输出
只是 2026 的主流使用方式里，Gin 最常见的确是 API 和微服务入口层。