revel验证码不能依赖session.delete异步清理，因其session是只读cookie快照；必须用redis存储并设ttl，校验前后均需原子删key，且前端失败后自动刷新。
Revel 中验证码不能靠 Session.Delete 异步清理
Revel 的 Session 是加密签名的 Cookie，每次请求解析出一个只读快照，响应结束即销毁。调用 delete(c.Session, "key") 只影响本次响应序列化的 Cookie，对下一次请求无效；更别说用 time.AfterFunc 去异步删——那时 c.Session 早已被 GC 回收，操作完全无意义。
正确做法是：写入时存时间戳，读取前做时效判断。比如存验证码时一并写入 "lastSeen" 字段（Unix 时间戳字符串），校验前先检查是否超时（如 ≥60 秒），超时则跳过使用，并可主动 delete(c.Session, CSecurityCode) + delete(c.Session, "lastSeen")，再调用 c.Session.Save() 确保下次请求不误读。
-
CSecurityCode和"lastSeen"必须成对写入，且都需c.Session.Save() - 校验逻辑必须放在业务 handler 入口处，不能依赖“事后清理”
- 前端刷新验证码时，后端要重置这两个字段，否则旧码可能被误校验
验证码存储必须用 Redis，不能只靠 Revel Session
Revel 默认的 Session 机制不适合验证码场景：它不支持跨请求共享、无法集群部署、没有 TTL 自动过期能力。一旦用户第一次请求生成验证码打到 A 实例，第二次提交打到 B 实例，B 根本读不到 A 写的 c.Session 数据，必然校验失败。
所以生产环境必须外接 Redis 存储验证码值。典型流程是：
- 前端调用
/captcha接口，后端生成随机字符串 + UUID，把字符串存入 Redis（key 为"captcha:" + uuid，TTL 设为 60–120 秒） - 接口返回
uuid给前端，前端拼进登录表单一起提交 - 登录 handler 中，从请求参数取
uuid和用户输入的code，用redis.Get("captcha:" + uuid)获取原始值比对 - 比对成功后立即
redis.Del("captcha:" + uuid)，确保一次性使用
Redis 操作必须原子、带 TTL，否则会留下脏数据或导致重放攻击。
校验失败时不要只返回错误，要同步刷新验证码状态
用户输错验证码后，如果只是返回 “验证码错误”，而没清掉当前 uuid 对应的 Redis 缓存，那他立刻重试仍会用同一个旧码——等于给了攻击者无限次暴力尝试机会。
正确处理是：校验失败时，也执行一次 redis.Del("captcha:" + uuid)，强制作废该次验证码。同时前端应自动触发一次新 /captcha 请求，拿到新 uuid 和新图片，避免用户手动刷新页面。
- 后端不区分“输错”和“超时”，只要校验未通过，就删 Redis key
- 前端需监听校验失败响应，自动调用
getCodeImg()并更新codeUrl和loginForm.uuid - 若依框架的前端逻辑可直接参考：它在响应拦截器里统一处理了失败后的刷新动作
Revel 的 Validation 不适合做验证码主校验
Revel 内置的 c.Validation 是为表单字段格式校验设计的（如非空、长度、正则），它运行在请求解析后、handler 执行前，但此时你还没拿到 uuid，也没法查 Redis。强行塞进去会导致两个问题：
- 校验逻辑提前执行，但 Redis 查询必须异步或阻塞等待，破坏 Revel 的同步 handler 模型
- 错误提示绑定在字段名上（如
.errors.code），而验证码校验失败是业务级判断，不是字段格式问题，不该混进Validation上下文
应该把验证码校验写在 handler 主体里，用 if code != storedCode 显式判断，失败时直接 c.RenderError("验证码错误") 或重定向回登录页，并确保 Redis key 已删。Validation 留给 username/password 这类基础字段即可。
真正容易被忽略的是：Redis key 的命名空间和 TTL 必须严格一致，且所有写入/读取/删除操作都要加日志埋点——线上出问题时，你唯一能查的只有 Redis 里的 key 是否存在、值是否匹配、过期时间是否准确。
