base64captcha最省心但易踩三坑：字体路径错误、大小写/空格未处理、id直接当凭证用。id仅作存储键，须配redis+ttl防重放；校验前需trim和tolowercase；中文需driverchinese+绝对字体路径；store必须全局单例且线程安全。
base64Captcha 是目前 Go 生产环境最省心的选择，它把字体加载、噪点叠加、PNG 编码、base64 封装全包了，不用自己拼 image/png buffer，也不用操心 HTTP 头。但直接 go get 就跑，90% 会卡在字体路径、大小写校验或 ID 存储这三关。
为什么 base64Captcha.GenerateCaptcha 返回的 ID 不能直接当 session key 用
这个 ID 只是服务端存储答案时用的 map 键（比如 "f8a3e7b1_answer"），它本身不加密、不签名、无访问控制。攻击者只要拿到这个 ID，就能反复调用后端校验接口——如果后端没做限流或 IP 绑定，等于把答案白送。
- 别把
ID当凭证返回给前端后就不管了；必须同步存一份答案到 Redis，带 TTL（如SET captcha:f8a3e7b1 "K7mN" EX 120） - 内存
map[string]string存答案必须配time.AfterFunc清理，否则 goroutine 泄漏+内存涨死 - 多个实例部署时，绝对不能只用本地 map —— 答案得存在共享存储里，ID 才有意义
验证码总提示“错误”，但人眼完全一样，问题在哪
几乎 100% 不是图糊，而是字符串处理环节掉链子。默认配置下 base64Captcha 区分大小写、不 trim 空格、保留易混淆字符（比如 0 和 O）。
- 前端
<input>提交前必须.trim()，后端接收后也得用strings.TrimSpace - 初始化 config 时显式禁用易混淆字符：
config.Source = "23456789ABCDEFGHJKLMNPQRSTUVWXYZ" - 校验前统一转小写：
strings.ToLower(input)，或设config.CaseSensitive = false - 别信日志里打印的
store.Get(id)值——它可能已过期返回空字符串，先GET检查 key 是否存在更可靠
Windows/macOS 下验证码显示方块字，怎么换字体
base64Captcha 默认用 DejaVuSans，但 Windows 没这字体，macOS 的系统字体路径又不一致，直接 panic 报错 open /xxx/font.ttf: no such file or directory，不是静默降级。
- Windows 推荐用
"C:/Windows/Fonts/msyh.ttc"（微软雅黑），macOS 用"/System/Library/Fonts/PingFang.ttc" - 别传字体名，必须传绝对路径；Docker 部署时记得把字体文件 COPY 进镜像，并用
os.ReadFile预加载进内存再传给NewDriverChinese或NewDriverString - 中文支持要换
driverChinese，且必须用captcha.NewCharacter而非captcha.NewDigit，否则直接 panic
并发请求下验证码状态错乱，根本原因是 store 复用不当
很多人在 handler 里每次 new 一个 captcha.Captcha 实例，或者复用同一个全局实例但没配线程安全 store。结果就是 A 用户的 ID 被 B 用户覆盖，或者答案被提前清掉。
- 全局只初始化一次
captcha.NewCaptcha(...)，它的store必须是线程安全的（比如redis.Store或带 mutex 的内存 store） - 别在 handler 里临时 new driver 或 config——字体解析耗 CPU，且并发多时容易触发文件打开数超限
- Redis store 的 key 建议加盐，比如
"captcha:" + base64.URLEncoding.EncodeToString(randBytes(12))，防枚举
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
