不用 github.com/disintegration/imaging；推荐用 github.com/mojocn/base64captcha，它纯 go 实现、支持多种模式、返回 base64 图片和答案，无需 cgo，但需注意 id 存储与清理、大小写敏感、易混淆字符过滤及并发安全。
验证码图片生成要用 github.com/disintegration/imaging 吗？
不用。Go 标准库没有图像绘制能力，但轻量级验证码不需要完整图像处理库。golang/freetype 太重，disintegration/imaging 是做缩放/滤镜的，不负责绘图。真正够用的是 image/draw + image/color + 字体渲染方案，或者更直接的——用现成的、专注验证码的包：github.com/mojocn/base64Captcha。
- 它内置了数字+字母混合、算术题、中文（需额外字体文件）三种模式，返回 base64 图片和答案，省去 HTTP 响应头、MIME 类型、缓存控制等胶水代码
- 不依赖 CGO，纯 Go 实现，交叉编译无压力（比如从 macOS 编译 Linux arm64 二进制）
- 默认字体是 DejaVuSans，Windows 下可能显示方块——得替换为本地存在的 TrueType 字体路径，比如
"C:/Windows/Fonts/msyh.ttc"或"/System/Library/Fonts/PingFang.ttc"
base64Captcha.GenerateCaptcha 返回的 ID 怎么用？
ID 不是 session key，也不是加密 token，它只是服务端存储验证码答案时用的 map key。你必须自己把它和答案一起存到内存、Redis 或其他地方，并在后续校验时取出比对。
- 别直接把 ID 当作可公开暴露的凭证返回给前端——攻击者拿到 ID 就能查答案（如果后端没做访问控制）
- 典型错误：用
map[string]string存在内存里，没设 TTL，导致内存泄漏；正确做法是搭配time.AfterFunc或用 Redis 的SET key value EX 120 - ID 本身是随机字符串（如
"f8a3e7b1"），长度固定 8 位，不可预测，但也不需要你自己生成——base64Captcha.GenerateCaptcha已返回
校验时为什么总提示“验证码错误”，明明肉眼看起来完全一样？
不是识别不准，是大小写、空格、零 O、数字 1 和字母 l 混淆了。base64Captcha 默认开启大小写敏感，且不会自动 trim 空格或做字符归一化。
- 前端 input 输入框可能有首尾空格，提交前务必
.trim()；后端接收后也要用strings.TrimSpace - 验证码默认包含易混淆字符：0/O, 1/l/I。建议初始化 config 时显式禁用：
config.Source = "23456789abcdefghijkmnpqrstuvwxyz" - 用户截图识别、手机拍照识别会引入轻微扭曲，但 base64Captcha 生成的是清晰无噪点图，所以问题几乎 100% 出在前后端字符串处理环节，而非图像质量
并发请求下验证码状态错乱怎么办？
多个请求共用一个 base64Captcha.Captcha 实例会导致内部随机数种子被覆盖，生成重复 ID 或答案错位。这不是 bug，是设计使然——它不是线程安全的。
- 每个请求都该新建 config 和 captcha 实例，不要复用全局变量
- 别在 handler 里写
var c = base64Captcha.NewCaptcha(...)—— 这个c是单例，所有 goroutine 共享其 rand.Rand - 正确姿势：每次调用
base64Captcha.GenerateCaptcha都传入新 config，函数内部会创建独立的绘图上下文和随机源
最常被忽略的一点：验证码答案一旦被校验过，就应该立即从存储中删除，无论成功失败。否则重放攻击只需拿着旧 ID + 旧答案反复提交。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
