base64captcha是golang生产环境首选验证码框架，核心优势在于稳定、可维护、易集成；其关键配置包括固定宽高（如120×40）、剔除易混淆字符、合理设噪声数，生产必须用redis替代内存store，并严格校验id清洗、大小写一致性及存储接口实现。
base64Captcha 是目前 Golang 生产环境里最常用、最省心的验证码框架，它不是“高性能”的代名词，而是「稳定、可维护、易集成」的现实选择。硬拼并发 QPS 没意义——验证码本质是低频、带状态、需防刷的交互环节，真瓶颈从来不在绘图，而在存储读写和校验逻辑。
为什么别自己用 golang.org/x/image 从头画验证码
你确实能用 truetype.Parse 加 draw.Draw 控制每个像素，但实际踩坑远多于收益：
– 字体加载必须提前完成，ioutil.ReadFile 放在 handler 里会触发每次请求都 IO，Docker 部署时若路径错直接 panic；
– 宽高低于 120x40 时抗锯齿失效，字符边缘发虚，OCR 识别率反而升高；
– 噪点用随机线段（draw.Line）容易被 OpenCV 的霍夫变换批量提取，换成半透明圆点才有效；
– 中文支持要自己解析 ttf 字节流，basicfont 只能画 ASCII，driverChinese 才真正可用，但它要求字体路径绝对且可读，相对路径在 systemd 或容器里基本失效。
base64Captcha 初始化时必须显式设宽高和字符集
很多人复制示例代码后发现图片模糊或字符挤在一起，问题出在 driver 配置缺失关键参数：
– Width 和 Height 必须固定，推荐 120 和 40，不要用 80x24 这类小尺寸；
– Length 设为 4 或 5，6 位以上用户输入错误率陡增；
– Source 别用默认全大写字母，必须剔除易混淆字符，例如用 "23456789ABCDEFGHJKLMNPQRSTUVWXYZ"（去掉 0/O/1/l/I）；
– NoiseCount 设 3~5 条干扰线即可，太多反而降低人眼识别率；
– 如果要用中文，必须用 NewDriverChinese，且传入的字体字节切片得来自 os.ReadFile("./assets/fonts/simhei.ttf")，不能只传文件名。
内存 store 仅限调试，生产必须换 Redis
base64Captcha.DefaultMemStore 看似方便，但有三个致命缺陷：
– TTL 固定 10 分钟不可调，无法对齐前端倒计时（比如你前端只显示 5 分钟，后端却存 10 分钟）；
– 没有自动清理机制，高并发下 map 不断膨胀，OOM 风险真实存在；
– 多实例部署时完全不共享，用户请求 A 实例生成，再打到 B 实例校验，必失败。
正确做法是实现 base64Captcha.Store 接口，重点覆盖：
– Set(id, answer, expire)：用 Redis 的 SET captcha:{id} {answer} EX {expire}；
– Get(id, clear bool)：先 GET 再判断是否 DEL，clear=true 时务必删除 key；
– key 名建议加盐，比如 "captcha:" + base64.URLEncoding.EncodeToString([]byte(id + salt))，防暴力枚举。
校验失败时别急着改逻辑，先查这三处
VerifyString 返回 false，90% 不是代码写错，而是数据没对齐：
– 用户提交的 id 从 query 或 json body 解析后带空格或换行，必须 strings.TrimSpace(id)；
– Redis 里存的是小写答案，而前端把输入框 text-transform: uppercase 了，结果传过来是大写，比对自然失败；
– store.Get 返回的是 []byte，直接跟 string 比会永远 false，得先转成 string(answer)；
– 更隐蔽的是：前端用 fetch 提交时没设 Content-Type: application/json，Go 的 json.Unmarshal 把字符串首尾引号吞掉，导致传进来的 code 是 aB3x 而不是 "aB3x"。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
