base64captcha不支持滑动验证码，因其仅提供数字、字母、算术、中文和音频五种静态图像模式，所有驱动均生成单帧base64图片，缺乏缺口图/原图/滑块图分离、坐标偏移计算、轨迹行为分析等滑动验证必需能力。
滑动图形验证码不是 base64Captcha 原生支持的类型——它只提供数字、字母、算术、中文和音频五种模式，不包含滑块拼图类交互逻辑。真要实现滑动验证，得自己搭后端校验 + 前端拖拽逻辑，或换用专门库（如 dchest/captcha 也不支持滑动），目前 Go 生态里没有开箱即用的成熟滑动验证码 SDK。
为什么 base64Captcha 不能直接生成滑动验证码
base64Captcha 的所有驱动（DriverDigit、DriverString、DriverChinese、DriverMath）都基于单帧静态图像生成，输出是 base64 PNG/JPEG 字符串，不含缺口图、原图、滑块图三张图的分离能力，也没有坐标偏移、轨迹采样、行为特征分析等滑动验证必需的后端能力。
常见误操作是强行把“算术题”或“字符识别”包装成“滑动”UI，前端拖动后仍比对文本答案——这本质还是传统验证码，攻击者绕过 UI 直接 POST 答案即可，安全水位没提升。
- 它不生成缺口位置、滑块尺寸、背景图与模板图的像素级差异
- 没有内置轨迹时间戳、加速度、鼠标事件序列校验
- 存储结构只存字符串答案，无法关联“拖动距离是否合理”
想做滑动验证，实际要补哪些模块
必须手动实现以下三部分，缺一不可：
-
图像切分逻辑：用
image标准库读取原图，随机裁剪一块矩形作为滑块，再在背景图上挖空对应位置（注意抗缩放/抗旋转，避免简单像素比对失效） -
偏移量绑定与存储：生成时计算真实 X 偏移（单位 px），连同背景图 base64、滑块图 base64、ID 一起返回；该偏移值必须加密或混淆后存入
store（不能明文存），且 key 要绑定会话/IP -
前端行为+服务端复合校验：不只是比对最终位置，还要检查：
- 客户端上报的拖动轨迹点数是否少于阈值（防脚本直线拖动）
- 轨迹总耗时是否过短（
- 上报偏移值与服务端存储值误差是否在 ±5px 内（防四舍五入爆破）
更现实的替代方案：用现成服务或降级设计
自研滑动验证投入产出比极低，容易留下漏洞。推荐两种务实路径：
-
接入第三方 SaaS：如极验（Geetest）、腾讯防水墙、阿里云人机识别，它们提供 Go SDK（如
github.com/geetest/gt-go-sdk），返回 token + challenge，后端只需调/validate接口，不用管图像生成和行为模型 -
降级为增强型点击验证：用
base64Captcha的CaptchaModeArithmetic模式生成“12 + ? = 27”类题目，前端渲染成可点击数字区域，要求用户点击正确结果——比纯文本难 OCR，比滑动易实现，且能复用现有存储和生命周期管理
真正卡住落地的，从来不是“怎么画图”，而是“怎么证明拖动动作来自人类”。这个判断逻辑不在图像里，而在 HTTP 请求头、TLS 握手特征、JS 运行时环境指纹、以及你敢不敢把校验权重交给专业风控引擎。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
