gin.default()默认注入logger和recovery中间件，虽自身无状态，但开发者易在其中引入全局map计数、本地文件写堆栈等隐式状态操作，破坏微服务无状态性；需确保日志只输出、限流用redis、recovery无副作用。
微服务无状态设计不是“关掉 session 就完事”，而是一整套请求携带上下文、认证可验证、状态不落地的约束体系。Gin 本身不强制无状态，但它的中间件链和 Context 设计天然适配——关键在于你是否切断了所有隐式状态依赖。
为什么 Gin.Default() 默认中间件会悄悄破坏无状态性
gin.Default() 自动注入 Logger() 和 Recovery()，这两者本身无状态，但开发者常在日志中间件里偷偷写入全局 map 记录 IP 请求频次，或在 Recovery 中捕获 panic 后往本地文件写堆栈——这些操作让单个实例变成有状态节点。
- 真正无状态的日志中间件只做输出（如 stdout / Kafka），不查、不存、不查缓存
- 若需限流，必须用 Redis + Lua 原子脚本，而非内存计数器
-
Recovery()不应触发任何副作用（如发告警邮件、写本地日志文件），告警应交由统一可观测性组件异步处理
JWT 解析失败时，c.Abort() 和 c.Next() 的顺序陷阱
JWT 中间件里常见错误：解析失败后直接 c.JSON(401, ...) 却忘了 c.Abort()，导致后续 handler 仍被执行，可能暴露敏感数据或引发空指针 panic。
- 正确流程必须是：
if err != nil { c.JSON(401, ...); c.Abort(); return } - 哪怕只是校验
token.Valid，也要检查err == nil && token.Valid，因为jwt.Parse成功返回 token 但token.Valid == false很常见（如过期、签名校验失败） - 不要在中间件里调用
c.Redirect()或c.Data()后遗漏c.Abort()，Gin 不会自动中断链
路由参数与查询参数混用导致的幂等性丢失
比如设计 PUT /users/:id 更新用户，但业务逻辑里又去读 c.Query("force_update") 做分支判断——这个 query 参数不属于资源标识，却影响行为，破坏了 RESTful 的幂等契约，也使 CDN / 网关层无法安全缓存或重试。
- 资源操作应仅依赖路径参数（
:id）和请求体（JSON payload），所有控制开关必须进 body - 若真需外部控制（如灰度开关），应走 header（如
X-Env: staging），header 更易被网关统一透传且不参与缓存键计算 -
c.Param("id")和c.ShouldBindJSON(&v)是安全的；c.GetQuery("x")在无状态 API 中应视为危险信号
真正的难点不在 JWT 或路由写法，而在于所有中间件和 handler 都要默认假设「当前实例随时会被杀掉重启」——这意味着不能依赖本地内存变量、不能写本地磁盘、不能假设有前置请求已初始化某配置。Gin 提供了干净的执行容器，但填进去什么，还是得你自己把关。
