buffalo默认路由不支持图形验证码，因其无内置绘图能力，需手动设置content-type、写入png字节流，且id与明文必须分离存储校验。
验证码接口为什么不能直接用 Buffalo 默认路由
Buffalo 框架默认不带图形验证码生成能力，buffalo.New() 创建的 App 完全不处理图像渲染或随机字符串生成。你如果直接在 app.Post("/captcha", ...) 里写逻辑，会卡在「怎么画图」「怎么设响应头为 image/png」「怎么把字节流正确返回」这三步上——不是路由注册失败，而是 HTTP 响应体和 Content-Type 不匹配导致浏览器显示破损图标或下载乱码文件。
用 github.com/dchest/captcha 配合 Buffalo 渲染图片
这是最轻量、无 CGO 依赖、被 Buffalo 社区实际验证过的方案。它生成 base64 ID 和 PNG 字节流，你需要手动设置响应头并写入 body。
-
captcha.NewLen(6)返回一个 6 位随机字符串 ID，同时把对应明文存进内存 store（默认是 sync.Map） - 在 handler 里调用
captcha.WriteImage(c.Response(), id, 240, 80)，其中 240/80 是宽高，必须显式传 - 务必在
WriteImage前调用c.Response().Header().Set("Content-Type", "image/png")，否则前端 img 标签加载失败 - 不要用
c.Render()，它会套 HTML 模板，而验证码需要纯二进制响应
如何安全地返回验证码 ID 并避免 XSS
前端需要拿到 ID 才能后续提交校验，但不能把明文验证码一起返回。常见错误是用 JSON 返回 {"id": "xxx", "value": "abc123"}，这就彻底废掉了验证码意义。
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 只返回 ID：
c.JSON(200, map[string]string{"id": id}) - ID 本身是随机字符串，不包含可预测模式，无需额外加密
- 如果用 AJAX 获取验证码，确保后端接口路径没被 CSP 规则拦截（比如禁止 inline script 的情况下，别在 JS 里拼接
src="/captcha?i="+id） - 避免把 ID 放在 URL 查询参数里反复使用，每次请求都应调用
captcha.NewLen()生成新 ID
校验时为什么总是提示“验证码错误”
最常踩的坑是 store 不一致或过期时间错配。默认 captcha.DefaultStore 是内存型，但如果你启用了多进程（比如用 buffalo dev + 热重载），每个进程有独立 Map，ID 在 A 进程生成，却在 B 进程校验，必然失败。
- 开发期加一句
captcha.Store = captcha.DefaultStore强制复用单例，避免热重载分裂 - 校验用
captcha.VerifyString(id, input)，注意第二个参数是用户 POST 上来的字符串，区分大小写 - 默认过期时间是 10 分钟，如果页面停留太久，需前端主动刷新 ID 并清空输入框
- 别用
captcha.Reload(id)试图“续命”，它只重置计数器，不延长有效期
真正难调试的是 store 生命周期和并发读写——一旦上了负载均衡或容器多副本，就必须换 Redis store，而 buffalo+captcha+redis 的组合没有开箱即用封装，得自己实现 captcha.Store 接口。
