Gin默认无状态友好，因其不内置Session、不自动维护用户上下文，仅提供一次性请求上下文c，所有处理基于当前请求数据；JWT认证应避免c.Set()误用，Cookie/Session需自行集成第三方库实现。
Gin 本身不强制要求无状态，但它的设计天然适配无状态 API 开发——关键在于你不用手动维护会话，也不依赖框架内置 Session 存储。
为什么 Gin 默认就是无状态友好的
Gin 的 gin.Default() 只注入了日志和 panic 恢复中间件，不带任何服务端状态管理。它不会自动写 session、不绑定 http.Cookie、不维护用户上下文映射表。所有请求处理函数（func(c *gin.Context)）接收的 c 是一次性的，里面没有隐式共享的状态容器。
- 路由匹配、参数解析、JSON 绑定都基于当前请求数据，不跨请求缓存用户身份
-
c.Request和c.Writer是标准 net/http 对象，Gin 不做额外封装来“记住”前一个请求 - 如果你没显式调用
c.Set()或往c.Keys写东西，c就是干净的
JWT 认证时别误用 c.Set() 存用户实体
很多人在 JWT 中间件里解析完 token 后，习惯性调用 c.Set("user", user)，然后在 handler 里用 c.MustGet("user") 取值。这看起来方便，但容易埋坑：
- 如果中间件顺序错位（比如认证中间件没跑，handler 却直接取
"user"），MustGet会 panic -
c.Set()只在当前请求生命周期有效，不是“全局 session”，但它可能被误当成持久化凭据 - 更安全的做法是：每次需要用户信息时，从 header 解析 token → 验证 → 查询 DB（或缓存），或把 user ID 作为 context.Value 传下去，而非依赖
c.Keys的字符串键
示例中应避免：
立即学习“go语言免费学习笔记（深入）”；
func AuthMiddleware() gin.HandlerFunc {
return func(c *gin.Context) {
tokenStr := c.GetHeader("Authorization")
// ... 解析 token 得到 userID
c.Set("user_id", userID) // ✅ 可以，但仅作临时传递
// c.Set("user", fullUserStruct) // ❌ 不推荐，结构体可能含敏感字段且易被意外暴露
c.Next()
}
}
Cookie 和 Session 不是 Gin 的默认选项
Gin 对 http.SetCookie() 和 http.Request.Cookies() 提供了封装（c.SetCookie() / c.Cookie()），但这些只是对标准库的薄包装，不提供加密、签名、存储后端等 Session 能力。也就是说：
- 你要自己决定 Cookie 是否
HttpOnly、Secure、SameSite - 没有内置的
session.Store，也不会自动帮你序列化/反序列化用户数据 - 若真要用服务端 Session（比如登录态存 Redis），得自己集成
gorilla/sessions或类似库，而不是靠 Gin 提供
换句话说：Gin 把“有状态”这件事完全交给你决策，它只负责把请求和响应管道打通。
真正影响无状态落地的是你的中间件和业务逻辑
框架只是工具，无状态与否最终由你写的代码决定。最容易破坏无状态性的几个点：
- 在 handler 里直接操作全局 map 或 sync.Map 缓存用户 token → 这会让水平扩展失效
- 用
time.Now().Unix()做唯一 ID 而不加节点标识 → 多实例下 ID 冲突 - 依赖本地文件读写（如配置、临时 token 存盘）→ 容器重启后丢失，且多副本不同步
- 数据库事务里写入未加锁的共享计数器 → 并发更新导致数据错乱
只要这些地方都走外部服务（Redis、DB、JWT 签名验证），Gin 的路由和中间件链就天然保持无状态。最常被忽略的其实是日志中间件——如果它偷偷把用户 IP + token 写进本地文件，那这个服务就不再是纯无状态了。
