无状态认证在Iris中必须用JWT且服务端只校验不存储；ctx.Values()仅限单请求内存映射，不跨请求共享，不破坏无状态性；JWT密钥与算法须严格匹配；Token刷新应采用双Token模式，不可服务端续期；exp字段为秒级时间戳，非毫秒。
无状态认证在 Iris 中必须用 JWT，且 Token 必须由客户端携带、服务端只校验不存储——任何把 token 存 Redis 或数据库的方案都违背“无状态”前提。
为什么 ctx.Values().Set("user_id", ...) 不破坏无状态性
Iris 的 ctx.Values() 是请求生命周期内的内存映射，随每次 HTTP 请求新建、销毁，不跨请求共享，也不写入外部存储。它只是框架内部传递数据的临时容器，和 session、cookie、Redis 无关。只要你不把它序列化进响应头或存到持久层，就完全符合无状态定义。
- 常见误操作：在中间件里把
claims.UserID写进数据库日志表，或塞进全局 map 缓存 → 这会让认证逻辑产生状态依赖 - 正确姿势：解析完 JWT 后，仅用
ctx.Values().Set("user_id", claims.UserID)供后续 handler 读取，handler 处理完即丢弃 - 注意：不要在中间件里调用
ctx.Session().Set(...)—— Iris 默认不启用 session，启用了就不是无状态了
jwt.ParseWithClaims 的密钥和签名算法必须严格匹配
JWT 校验失败往往不是代码逻辑错，而是算法或密钥不一致。Iris 本身不封装 JWT，全靠 github.com/golang-jwt/jwt/v5（或 v4）驱动，因此必须手动对齐：
大模型 Token 成本节约工具。在请求到达大模型之前自动压缩 prompt 和上下文，减少 60-95% 的 token 消耗，直接降低 API 成本。支持 Claude/OpenAI/Gemini 等主流模型，提供代理模式、CLI 包装、Python SDK 和 MCP Server 四种接入方式。内置一键安...
- 前端传的是
HS256签名，后端就不能用RS256去 parse；反之亦然 -
func(t *jwt.Token) (interface{}, error)返回的密钥必须和签发时完全一致——字符串不能多空格、不能错大小写、不能漏换行符 - 若用公私钥（
RS256），ParseWithClaims的第三个参数要返回*rsa.PublicKey，且必须提前从 PEM 解析好，不能每次请求都重解析 - 建议加一行日志：
if t.Method.Alg() != jwt.SigningMethodHS256.Name { ctx.StopWithStatus(iris.StatusBadRequest); return }，快速定位算法错配
Token 刷新不能靠服务端“续期”，得用双 Token 模式
真正的无状态下，服务端无法主动使 Token 失效，也无法延长其有效期。所谓“刷新 Token”，本质是客户端用短期有效的 access_token + 长期有效的 refresh_token 换新 access_token，而 refresh_token 本身也需校验签名、检查是否被撤销（这时才需要查 DB 或 Redis）。
- access_token：有效期短（如 15 分钟），纯 JWT，服务端只校验签名和 exp，不查库
- refresh_token：有效期长（如 7 天），同样为 JWT，但签发时记录 jti（唯一 ID）到 Redis，校验时先查 jti 是否存在且未被标记为 revoked
- Iris 路由中实现刷新接口时，
authMiddleware只作用于 access_token；刷新接口本身应绕过该中间件，改用独立校验逻辑处理 refresh_token - 别在 Iris 中写“自动延长 Token 过期时间”的逻辑——那等于在服务端维护状态，和无状态目标直接冲突
最容易被忽略的一点：JWT 的 exp 字段是秒级时间戳，不是毫秒。前端若用 Date.now() 直接填，会导致服务端永远校验失败；后端签发时也要确认 time.Now().Add(15 * time.Minute).Unix()，而不是 .UnixMilli()。
