Iris本身不内置JWT生成逻辑，需依赖第三方库；必须显式设置SigningMethod和密钥，用jwt.NewToken创建实例后通过SignedString签名，漏掉任一环节会导致panic或token无效。
JWT生成必须用jwt.NewToken配合密钥和签名算法
Iris本身不内置JWT生成逻辑，它依赖第三方库（如github.com/golang-jwt/jwt/v5）完成编码。直接调用jwt.NewToken创建实例后，必须显式设置SigningMethod（比如jwt.SigningMethodHS256），再通过claims填入用户数据。漏掉签名方法或密钥会导致token.SignedString() panic 或返回空字符串。
常见错误现象：panic: unsupported algorithm: none 或生成的 token 缺少第三段（signature）。
- 密钥必须是
[]byte类型，不能直接传字符串字面量；建议从环境变量读取，避免硬编码 - payload 中不要放敏感字段（如密码、身份证号），JWT 默认不加密，仅做签名防篡改
- 过期时间必须用
time.Time对象设置exp字段，不能只传秒数——jwt.MapClaims{"exp": time.Now().Add(24 * time.Hour).Unix()}才有效
Iris中间件里验证token要手动解析并校验token.Valid
在Iris中写鉴权中间件时，不能只靠ctx.GetHeader("Authorization")拿到字符串就放行。必须用jwt.Parse解析，并严格检查token.Valid == true，否则攻击者可构造无效或过期 token 绕过校验。
典型疏漏：只判断err == nil就认为 token 有效，但jwt.Parse在过期时返回err != nil且token != nil，此时token.Valid为false，必须显式判断。
- 解析时密钥函数必须返回非空
[]byte，返回nil会触发key is not valid错误 - 推荐用
ctx.Values().Set("user_id", uid)把解析出的用户ID存入上下文，后续 handler 直接取用，避免重复解析 - 不要在中间件里对每个请求都查数据库验证用户存在——JWT 本身已含身份声明，除非业务强制要求实时状态同步（如封禁立即生效）
Token颁发路径要避开静态资源和登录接口本身
如果你把 JWT 鉴权中间件全局注册（app.Use(authMiddleware)），又没排除/login或/public/这类路径，会导致登录请求被拦截，永远拿不到 token。
正确做法是用app.Party分组路由，让未鉴权路径走独立子树：
auth := app.Party("/api", authMiddleware)
auth.Get("/user", getUserHandler) // 受保护
app.Post("/login", loginHandler) // 不受保护，可生成token
app.StaticWeb("/public", "./static") // 明确排除- 别用
ctx.Next()代替路径过滤——中间件执行顺序不等于路由匹配顺序 - 前端发登录请求时，确保 header 没带
Authorization，否则 Iris 可能提前触发鉴权逻辑 - 如果用 Cookie 存 token，注意
Secure和HttpOnly标志位，避免 XSS 泄露
刷新token不能只延长exp，得重签新token
JWT 一旦签发就不可修改。想“刷新”token，不是在原 token 上改exp字段，而是服务端重新生成一个新 token，并返回给客户端替换旧值。否则客户端拿着过期 token 还在用，后端解析时token.Valid始终为false。
容易被忽略的细节：刷新接口本身也需鉴权（用旧 token），且应限制刷新频率（如 15 分钟内只允许一次），防止暴力轮询。
- 新 token 的
iat（签发时间）必须更新，不能复用旧值，否则无法准确判断刷新链路 - 若业务需要“单点登出”，JWT 本身不支持主动失效，得配合 Redis 黑名单或短生命周期 + 强制刷新策略
- 别把 refresh token 和 access token 混在一个 JWT 里——它们安全等级不同，应分开签发、分开存储、分开过期
Iris 对 JWT 是零抽象封装，所有解析、签发、校验逻辑都得自己写死在 handler 或中间件里。最易出错的不是语法，而是忘记检查token.Valid、误以为err == nil就万事大吉，或者在不该鉴权的地方加了中间件。
