生产环境应使用 gocaptcha 而非手写 image/draw：它默认集成抗 OCR 扭曲、随机噪点、多字体混合，支持 Redis 存储（需设 TTL、带 hash tag），避免手动实现的安全与并发缺陷。
验证码生成用 gocaptcha 还是手写 image/draw？
直接说结论：生产环境别自己手写图形验证码渲染逻辑。看似简单，实则容易漏掉抗 OCR、防重放、字体模糊、噪点干扰强度等关键安全细节。推荐用经过实战检验的 gocaptcha（注意不是已归档的 go-captcha），它默认启用扭曲 + 随机噪点 + 多字体混合，且支持内存/Redis 存储后端。
如果必须自定义（比如要嵌入公司 logo 水印），可在 gocaptcha 基础上扩展其 DrawFunc，而不是从 image/draw 重头画起——后者连中文字符对齐、抗锯齿、透明度叠加都得反复调参。
gocaptcha 的存储后端怎么选？Redis 是唯一靠谱选项
本地内存（store.NewMemoryStore()）只适合单机调试。一旦部署多实例或重启服务，用户提交的验证码就必然校验失败。错误现象是：captcha.VerifyString(id, user_input) 总返回 false，但日志里看不出原因。
- 用 Redis 时，务必设置 TTL（如
60 * time.Second），避免 key 泛滥 - 不要复用全局
redis.Client实例做并发写入；gocaptcha内部不加锁，高并发下可能覆盖验证值 - 若用 Redis Cluster，需确保
id字符串带 hash tag（如{captcha}abc123），否则GET和DEL可能落在不同节点
前端传参和后端校验的常见断点
最常踩的坑不是算法，而是 HTTP 协议层的疏忽：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 前端
fetch发送校验请求时，没带Content-Type: application/json，导致 Go 的json.Decode静默失败，captcha_id和value全为零值 - 后端接收结构体字段没加
json:tag，例如写成type VerifyReq struct { CaptchaID string; Value string }，实际必须是CaptchaID string `json:"captcha_id"` - 验证码 ID 由前端生成（如
Math.random()）——这是严重漏洞，攻击者可预测 ID 并暴力穷举，ID 必须由后端生成并返回
为什么 captcha.VerifyString() 返回 true 后还要手动 store.Remove()？
因为 VerifyString 默认只是读取并比对，并不自动清理。不删会导致同一验证码被重复使用（比如用户故意多次提交同一组 id+value）。正确流程是：
if ok := captcha.VerifyString(id, userInput); ok {
store.Remove(id) // 必须显式删除
// 继续处理登录/注册逻辑
} else {
http.Error(w, "验证码错误", http.StatusUnauthorized)
}更稳妥的做法是把 Remove 放在 defer 里，防止后续逻辑 panic 导致残留；但要注意：如果校验失败，就不该删——否则用户刷新页面后无法重试，得重新请求新验证码。
