验证码必须在后端生成，前端仅展示和提交；后端需将明文存入session或redis并返回captchaid，校验后立即销毁，canvas绘制时注重干扰而非复杂度，图片url须加时间戳防缓存，刷新验证码需前后端同步更新id与值。
验证码该在后端生成还是前端生成
必须在后端生成，前端只负责展示和提交。前端生成的验证码（比如用 Math.random() 拼字符串）毫无安全意义——用户直接看源码或调用 JS 就能绕过。
常见错误现象：400 Bad Request 或始终校验失败，本质是前后端验证码值不一致；更隐蔽的是，前端生成后没传给后端校验逻辑，导致校验永远走默认分支。
- 后端生成后，把验证码明文存入 session（如
req.session.captcha）或 Redis（带 TTL），同时返回一个唯一标识（如captchaId）给前端 - 前端把
captchaId和用户输入的值一起提交，后端用captchaId查出原始值比对 - 校验成功后立即销毁该验证码（
delRedis key 或req.session.captcha = null），防止重放
怎么用 Canvas 绘制带干扰的图形验证码
Canvas 是目前最轻量、兼容性好、且不易被 OCR 批量识别的方式。关键不是“画得多复杂”，而是破坏字符间距、叠加噪点、扭曲路径——但别过度，否则用户也识别不了。
使用场景：登录页、注册页、评论提交前等需要防机器刷的表单入口。
立即学习“前端免费学习笔记（深入）”；
- 服务端生成 4~6 位随机字符串（
Math.random().toString(36).substr(2, 4)不够安全，建议用crypto.randomBytes(3).toString('hex')） - 用 Node.js 的
canvas包（或 PHP 的 GD、Python 的 PIL）绘制：先填底色，再逐字符用不同字号/角度写入，最后画几条lineTo()干扰线、散落几个fillRect()噪点 - 务必设置响应头：
res.set('Content-Type', 'image/png')，并直接res.send(buffer)输出二进制流，不要 base64 编码塞进 HTML
为什么验证码图片地址要加时间戳参数
避免浏览器缓存导致用户看到旧验证码。典型表现：刷新页面后图形没变，输错几次才发现其实是同一个图。
这不是“最佳实践”，而是必选项。哪怕后端已设 Cache-Control: no-cache，某些浏览器或中间代理仍可能缓存 GET 请求。
- 前端 img 标签这样写：
<img src="/captcha?r=" date.now alt="HTML表单怎样生成验证码_HTML表单生成验证码方法【教程】" > - 不要用
Math.random()，它在 React/Vue 等框架中可能被批量调用，造成重复时间戳（尤其快速点击刷新时） - 后端路由需忽略
r参数，只认captchaId（如果用了 ID 机制），否则会因参数不同误判为新请求
校验失败后如何安全地刷新验证码
不能只换图片，必须同步更新后端存储的验证码值和对应 ID。否则用户看到新图，但提交的仍是旧 captchaId，校验必然失败。
容易踩的坑：前端点了“换一张”只改了 img.src，却没拿到新的 captchaId；或者后端生成新验证码时没删旧的，Redis 里堆了一堆未过期的无效值。
- 推荐方案：点击“换一张”时，先发一个
POST /captcha/refresh请求，后端返回新的{id: "abc123", image_url: "/captcha?c=abc123"} - 前端用新
id替换隐藏域中的值，并更新img.src；表单提交时带上这个最新id - 后端
/captcha/refresh接口必须原子性操作：生成新验证码 → 存 Redis（带 5 分钟 TTL）→ 删除旧 key（用传入的旧id）
真正麻烦的从来不是画图，而是让每次“换一张”都精准对应一次服务端状态变更。ID 生命周期、TTL 设置、并发刷新时的 key 冲突——这些细节漏掉一个，验证码就形同虚设。
