直接使用 github.com/mojocn/base64Captcha 库最省事，它内置数字、字母、算术题三种模式，支持 base64 返回和 HTTP 响应流；生产环境必须用 Redis 或 Memcached 替代默认内存 store，配置宽高 120×40、长度 4–5、答案带 TTL 存储，验证前需 trim 输入、注意大小写与空格、确保字符串类型一致，并保障 store 线程安全及 Redis 连接池合理配置。
验证码图片生成用 github.com/mojocn/base64Captcha 最省事
直接用这个库，不用自己拼接字体、噪点、扭曲逻辑。它内置了数字、字母、算术题三种模式，支持 base64 返回，也支持写入 HTTP 响应流，适配 Web 场景非常顺。
常见错误是忽略 store 的生命周期管理——默认内存 store 会随进程重启丢失所有验证码，生产环境必须换 redis 或 memcached。示例中常看到 captcha.DefaultMemStore，那只是开发调试用的。
关键配置点：
-
width和height建议设为 120×40，太小识别率低，太大前端缩放易模糊 -
Length设为 4 或 5，6 位以上用户输入错误率明显上升 - 启用
AudioEnable: true时需额外加载音频资源，Web 端还要处理<audio>标签，多数项目其实不用
验证码 ID 和答案必须绑定存储，且带 TTL
用户请求验证码时，base64Captcha.GenerateCaptcha() 返回一个 id 和 base64 图片字符串，但真正要验证的是 id 对应的答案（比如 "aB3x"）。这个答案不能存在内存变量里，也不能存进数据库不设过期时间。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
正确做法是用带 TTL 的键值存储：
- Redis：用
SET key value EX 300（5 分钟过期），key 是 captcha id，value 是明文答案 - 如果用
github.com/mojocn/base64Captcha，直接传入自定义store实现，它会在生成和验证时自动调用Set/Get/Verify - 切勿把答案塞进 cookie 或前端 hidden input——这是典型安全漏洞，攻击者可伪造验证
VerifyString 验证失败的常见原因不是逻辑错，而是大小写和空格
base64Captcha.VerifyString(id, answer) 返回 false 时，90% 情况下不是代码 bug，而是用户输入或传输过程引入了干扰：
- 前端没 trim 输入框内容，用户末尾多敲了个空格
- 验证码生成时用的是大小写混合模式，但前端表单转成了全小写再提交
- HTTP 请求头没设
Content-Type: application/json，导致 Go 的json.Unmarshal把字符串首尾引号吃掉，传进来的answer变成aB3x而不是"aB3x" - Redis store 中取出来的答案是
[]byte，但没转成string就直接比对（Go 里[]byte和string不等价）
并发验证时要注意 store 的线程安全性
如果你自己实现了 Store 接口（比如包装一层本地 map），别忘了加 sync.RWMutex。默认的 DefaultMemStore 是线程安全的，但它的 RemoveAll 方法在高并发下可能漏删——这不是 bug，是设计使然：它只保证「尽量清理」，不承诺强一致性。
更现实的问题是 Redis store 的连接池配置。用 github.com/go-redis/redis/v8 时，opt.MinIdleConns 至少设为 5，否则大量并发请求验证码会卡在连接获取上，表现为超时或 502。
另外，VerifyString 内部会自动调用 store.Remove(id)，意味着一次验证成功后该 id 就失效——这点必须和前端同步好：不要允许“点刷新按钮重试”，而应强制走新请求获取新 id。
