iris通过jwt中间件实现请求身份验证，需用jwt.new创建实例，支持url参数或bearer头提取令牌，提供serve、checkjwt和get三种验证方法，并须在路由中注册中间件。
iris.Context 是整个认证流程的上下文载体，所有鉴权逻辑都围绕它展开。Iris 本身不强制绑定某一种认证方式，但提供了 sessions、jwt、中间件链等基础设施，你可以按需组合。关键不是“用什么”，而是“在哪做”和“怎么中断非法请求”。
登录成功后怎么存用户身份？别只设 session
单纯调用 session.Set("user_id", 123) 不够安全，也不利于后续扩展。Iris 的 sessions 包支持自动签名、过期控制和存储后端切换（内存/Redis），但必须配合显式配置：
- 使用
sessions.New创建 session 实例时，务必设置Expires（如time.Hour * 24）和Cookie.HttpOnly为true - 不要把明文密码、token 或敏感字段塞进 session；只存最小必要标识，比如
user_id或user_role - 若用 Redis 后端，需提前初始化
redis.Pool并传入sessions.Config{Database: redisPool}，否则默认走内存，集群下失效
JWT 认证怎么接入中间件？注意签发与校验分离
JWT 适合无状态场景，但 Iris 没有开箱即用的全局 JWT 中间件，得自己写。常见错误是把签发逻辑（登录接口里 jwt.Sign）和校验逻辑（访问受保护路由时 jwt.Verify）混在一起。
- 签发：登录成功后用
jwt.NewToken+token.Sign生成 token，并通过ctx.Header("Authorization", "Bearer "+tokenString)返回给前端 - 校验：在中间件中用
jwt.Parse解析 header 中的 token，失败则调用ctx.StopWithStatus(401)立即终止链，而不是ctx.Next() - 注意密钥管理：
jwt.HmacSha256的 key 必须从配置文件或环境变量读取，硬编码在代码里等于裸奔
为什么 ctx.User() 总是 nil？检查中间件注册顺序
Iris 的 ctx.User() 是空接口，需要你手动赋值。很多开发者以为它能自动识别登录态，其实它只是个占位符。
- 必须在认证中间件里显式调用
ctx.SetUser(user)（user可以是 struct、map 或自定义类型） - 中间件注册顺序决定执行时机：认证中间件必须在业务 handler 之前，且不能被其他
ctx.StopXXX提前截断 - 如果用了
Party分组路由（如app.Party("/admin")），中间件要注册在分组上，而不是全局 app 上，否则前台页面也会被拦
验证码和登录耦合太紧？拆到独立 handler 更可控
图形验证码（captcha）不是登录专属，它属于人机校验层，应该和账号密码验证解耦。
- 单独暴露一个
/captcha接口返回图片 base64 和 session ID，前端存好 ID 再提交登录 - 登录 handler 先调用
captcha.Verify校验输入，失败直接ctx.JSON(map[string]string{"error": "验证码错误"})并 return - 避免在登录成功后再去查一遍 session 验证码——此时 session 可能已被清空（如 captcha 库默认单次有效）
真正容易被忽略的是 session 与 JWT 的混合使用边界：比如用 session 存用户基本信息、用 JWT 做 API 调用签名，两者生命周期不同步就会出问题。上线前务必压测并发登录+登出场景，观察 session 清理是否及时、token 吊销是否生效。
