base64captcha 不支持拼图验证码，因其仅支持静态图像与字符串校验，缺乏坐标偏移计算、像素对齐校验、轨迹防模拟及容差比对能力；应选用 hcaptcha 或自研轻量服务，确保偏移加密存储、时效绑定与服务端可信验证。
base64Captcha 不支持拼图行为验证码，强行用它做拼图会掉进兼容性、校验逻辑和前端交互三重坑里。
为什么 base64Captcha 不能直接做拼图验证码
base64Captcha 的核心设计是「静态图像 + 字符识别」，所有驱动（DriverString、DriverChinese、DriverMath）都只生成固定图片+明文答案，不提供：
- 拼图块坐标偏移计算
- 背景图与滑块图的像素级对齐校验
- 滑动轨迹防模拟检测（如加速度、停顿点）
- 拖拽完成后的服务端位置比对逻辑
它的 store.Verify 只接受字符串比对，而拼图需要验证「用户拖动距离是否落在容差范围内」——这已经超出该库抽象能力。
替代方案：用 hcaptcha 或自研轻量拼图服务
真正可用的拼图行为验证码，要么集成成熟第三方，要么自己控制关键环节：
- hcaptcha 提供开箱即用的拼图/旋转/选择类行为验证，Gin 中只需透传 token 到其后端校验接口（https://api.hcaptcha.com/siteverify）
- 若需完全可控，建议用 image/draw + crypto/rand 自建：
- 生成一张背景图（带目标区域），再切出对应拼图块（含随机偏移）
- 把偏移值加密存入
store（如用base64Captcha.DefaultMemStore存 ID →map[string]struct{ X, Y, Tolerance int }） - 前端提交滑动距离
x，服务端解密查出真实偏移，判断abs(x - realX)
Gin 中拼图接口的关键参数设计
行为验证码必须携带上下文标识，否则无法绑定用户操作：
- 接口返回必须含 captcha_id（用于后续校验绑定）
- 前端提交时必须带该 captcha_id 和滑动值（如 slide_x）
- Gin 路由示例：
router.GET("/captcha/puzzle", getCaptcha)<br>router.POST("/captcha/verify", verifyPuzzle)
getCaptcha 函数里要生成图、算偏移、存状态；verifyPuzzle 里必须先从 captcha_id 查出原始偏移，再比对。漏掉任一环，就会出现「用户明明拖对了却提示失败」。拼图验证码的难点不在绘图，而在「如何让服务端可信地确认用户真的拖动了，而不是直接伪造请求」——这要求偏移生成、存储、校验全程隔离且带时效，任何一步用错结构或忽略清理，都会让安全形同虚设。
