Go Fiber 无内置图形验证码功能，需集成第三方库如 base64Captcha；生成接口返回 base64 图片与 ID，校验须用中间件、清空存储、防重放，并替换 Redis 保障多实例一致性。
Go Fiber 里没有内置图形验证码功能
Fiber 本身不提供 GenerateCaptcha、VerifyCaptcha 这类函数，也不带图像绘制能力。它只负责 HTTP 请求处理，验证码的生成和校验必须自己集成第三方库或手写逻辑。常见错误是直接搜 “fiber captcha”，然后试图调用不存在的 fiber.Captcha() —— 这会导致编译失败或运行时 panic。
用 github.com/mojocn/base64Captcha 实现最简流程
这个库轻量、无依赖、支持 base64 返回，适合 Fiber 快速接入。注意它默认用内存存储验证码值，生产环境需替换为 Redis。
- 安装：
go get github.com/mojocn/base64Captcha - 生成接口返回 base64 图片 + ID：
c.JSON(200, map[string]string{"id": id, "img": base64string}) - 校验时从
c.FormValue("captcha_id")和c.FormValue("captcha_value")取值，调用store.Verify(id, value, true) - 务必设
store.ExpireIn = 5 * time.Minute，否则验证码永不过期
校验中间件里容易漏掉的三件事
很多人把验证码校验写成普通 handler，但实际应封装为中间件，否则业务路由会重复写校验逻辑。关键点在于：校验失败不能只 c.Abort()，还要清空已存的 session 或 Redis 中对应 ID 的记录，防止重放。
- 未验证前不要执行
c.Next()，否则后续 handler 已开始执行 - 校验失败时要调用
store.Remove(id)，否则攻击者可反复尝试 - 前端传来的
captcha_id必须先做非空和长度校验，避免空 ID 触发 panic
Redis 替换内存存储的必要改动
默认的 base64Captcha.DefaultMemStore 只适用于单实例开发环境。上线后多实例部署时，用户请求可能打到不同机器，导致“图对但校验失败”。必须用 Redis 统一存储。
- 初始化 store 时改用
base64Captcha.NewRedisStore(redisClient) - 确保 Redis key 命名含前缀，如
"captcha:" + id，避免和其他业务冲突 - Redis 连接超时或失败时，
store.Verify()会返回 false，需在日志中明确记录 “redis verify failed” 而非 “captcha mismatch”
图形验证码不是加个中间件就完事的环节。真正难的是失效策略、存储一致性、以及和登录流程的耦合时机——比如是否允许三次输错后锁定 IP，这些逻辑不在框架里，得你一条条补上。
