使用 github.com/disintegration/imaging 可高效生成抗锯齿、带随机抖动文字与浅灰干扰线的验证码图，需指定绝对路径字体、筛选易混淆字符、设置正确 Content-Type 为 image/png，并用 Redis 安全存储带盐 key 与 TTL 控制。
用 github.com/disintegration/imaging 生成带噪点的验证码图
Go 原生 image 包能画，但加文字、抗锯齿、随机干扰线都得自己撸——容易出模糊字、中文乱码、字体路径错。直接上轻量第三方更稳。imaging 不依赖 CGO，纯 Go 实现，缩放/旋转/叠加都快，适合 Web 服务高频调用。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
imaging.New创建背景图，尺寸建议 120×40，太小识别率低，太大浪费带宽 - 调
imaging.DrawText写验证码文本时，务必传入绝对路径字体文件（如"./assets/fonts/arial.ttf"），相对路径在 Docker 或 systemd 下极易失效 - 每字符 x 偏移加随机抖动（±3px），y 偏移微调（-5~+5px），避免被简单模板匹配
- 用
imaging.Line画 3–5 条斜穿的浅灰干扰线，颜色设为color.RGBA{200,200,200,255}，太深会遮字，太浅没效果
验证码文本生成必须避开易混淆字符
用户输错不是因为看不清，而是 "0" 和 "O"、"1" 和 "l"、"i" 在小字号下几乎一样。不筛字符，前端再好看也白搭。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 预定义安全字符集：
"23456789ABCDEFGHJKLMNPQRSTUVWXYZ"（去掉 0,O,1,l,i,I） - 用
rand.Read+math/rand.New配合time.Now().UnixNano()初始化 seed，避免并发时多个 goroutine 拿到相同序列 - 长度固定 4–6 位，别用
rand.Intn(5)+4动态长度——OCR 工具对变长识别更准
HTTP handler 中写入图片响应的三个硬性检查点
常见错误是图片返回了但浏览器显示叉号，或提示 “Failed to load resource”，问题基本不出在绘图逻辑，而在 HTTP 头或编码环节。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 响应头必须设
w.Header().Set("Content-Type", "image/png")，少一个字母都不行；别用jpeg，压缩会导致文字边缘糊成一片 - 用
png.Encode(w, img)直接写入http.ResponseWriter，别先bytes.Buffer再写——多一次拷贝可能触发超时或内存暴涨 - 务必在
Encode后检查 error：如果字体加载失败，DrawText会静默跳过，但Encode可能 panic 或写入空图
Redis 存储验证码时 key 设计和 TTL 的坑
后端校验靠 Redis，但 key 写成 "captcha:" + phone 就等着被枚举爆破；TTL 设 5 分钟看似合理，实际用户填错一次后重试，倒计时还在走，体验断层。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- key 必须带随机盐值，例如
"captcha:" + base64.URLEncoding.EncodeToString(randBytes(12))，返回给前端的同时存一份映射（如"captcha_meta:" + salt存手机号和过期时间） - TTL 设 120 秒，但每次生成新验证码时，把旧 key
DEL掉——防止用户狂点“换一张”导致 Redis 积压大量过期键 - 校验时用
GETDEL而非GET+DEL，避免竞态：用户双击提交，两次请求可能都拿到同一个验证码
字体文件路径、Redis key 盐值、PNG 编码前的 error 检查——这三个点线上出过最多问题，修起来快，但漏掉一个就让用户卡在登录页反复刷新。
