直接用原生 image/draw + image/color 足够生成验证码图，无需 github.com/nfnt/resize；避免 ocr 的关键是逐字符随机偏移±5px/±3px、轻微旋转（-15°~+15°）、叠加自定义遮罩破坏连通性，并设 content-type 为 image/png、存 redis 带 ttl。
验证码图像生成用 github.com/nfnt/resize 还是原生 image 包？
直接用原生 image 包，别引入 resize 类依赖。验证码图尺寸小（通常 200×60 左右），不需要复杂缩放；resize 反而增加构建体积、带来 CGO 风险（尤其在 Alpine 容器里）。原生 image/draw + image/color 足够画背景、噪点、文字、干扰线。
如何避免验证码文字被 OCR 识别？
关键不是加多深的干扰线，而是破坏字符的连通性与结构完整性。实操建议：
- 文字逐个绘制，每个字符随机
x偏移 ±5px、y偏移 ±3px，再叠加轻微旋转（-15到+15度） - 用
draw.DrawMask对每个字符应用自定义image.Mask（比如带空心点或锯齿边缘的遮罩） - 背景填充用渐变色（
image.NewUniform不够，改用draw.Draw+ 线性插值计算像素） - 噪点密度控制在每 10×10 区域 1~2 个随机点，颜色从背景色系中采样，避免纯黑/白突兀点
http.Handler 中生成并返回验证码时，为什么前端总显示“损坏的图像”？
大概率是响应头或编码问题。常见错误现象：浏览器提示“无法加载图像”，但 curl -I 返回 200。检查这几点：
- 必须显式设置
w.Header().Set("Content-Type", "image/png")，不能依赖自动推断 - 写入前确保没有提前写入过响应体（比如日志误调用
fmt.Fprint(w, ...)导致 header 冲突） - 用
png.Encode(w, img)直接写入 ResponseWriter，不要先bytes.Buffer再写——中间多一次拷贝可能触发 flush 异常 - 如果用了自定义字体（
truetype.Parse），确认字体文件路径在运行时可读，且font.Face创建成功（nil face 会导致draw.String静默失败）
验证码字符串该存在内存还是 Redis？
存 Redis 是唯一合理选择。内存 map 在多实例部署下失效，且无法设置 TTL 自动清理。注意两个细节：
- key 命名别用裸 ID，推荐
"captcha:" + sessionID或"captcha:" + clientIP + ":" + timestamp，防爆破 - 存值时用
SET key value EX 300（5 分钟），但生成后立即GET一次确认写入成功——某些 Redis 配置（如只读从库）会导致 SET 成功但主从同步延迟，GET 拿不到 - 不要在生成接口里删掉旧 key，等用户提交验证时再
DEL；否则刷新页面会丢失验证码
字符混淆和存储分离做得再细，只要字体渲染逻辑没做抗锯齿裁剪、或者 PNG 编码漏了 png.Encoder 的 CompressionLevel 设置，图像边缘就容易出现规律性灰边——那是 OCR 最爱抓的特征。这点调试时得用 file.WriteTo 本地保存比对。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
