真正有效的防刷只能在服务端实现，前端禁用按钮、倒计时、存储状态等均易被绕过；验证码必须动态生成带唯一ID和时间戳参数，后端严格校验并立即销毁缓存，且校验须为请求处理第一步。
前端按钮防刷新只是障眼法，真防刷必须靠服务端
点击后禁用按钮、加倒计时、存 cookie 或 localStorage，这些操作全在客户端，用户刷新页面、清缓存、禁用 JS 或直接抓包重放，都能绕过。真正起效的防刷，只发生在服务端——前端做的所有事，只是降低普通用户的误操作率，不是对抗攻击者。
常见错误是把 setInterval 和 disabled = true 当成“防刷完成”，结果后端接口没做任何校验，攻击脚本一秒钟发 100 次请求照样成功。
- 按钮禁用状态必须配合服务端返回的成功响应才启动倒计时，不能点一下就开跑
- 倒计时结束时，必须清除服务端已下发的验证码会话（如 Redis 中的
captcha_id），否则用户可重复提交旧码 - 前端存储的剩余秒数（如 cookie 中的
intervalTime）仅作展示参考，不可用于服务端判断是否允许发送
图形验证码必须带唯一 ID，且每次请求都换图
验证码图片的 src 必须动态带参数，比如 /captcha?t=1721127722345 或 /captcha?r=abc123，否则浏览器或 CDN 会缓存同一张图，导致多次提交用同一个码值，形同虚设。
后端生成时要返回两个关键东西：一张 PNG 图片（Content-Type: image/png）+ 一个一次性 captcha_id（如 UUID），前者塞进 <img> 的 src，后者存进 hidden input 或 JS 变量，提交表单时必须一起带上。
立即学习“前端免费学习笔记（深入）”；
- 后端响应头必须设
Cache-Control: no-store, no-cache，禁用代理和浏览器缓存 - 不要用
Math.random()在前端生成字符再画到<canvas>上——那等于把明文直接暴露给攻击者 - Nginx 等反向代理若对
.png做了强制缓存，需单独排除/captcha路径
表单提交时后端校验顺序不能错
验证码校验必须是第一步，且失败就立刻中断，不查数据库、不发短信、不记录日志（或只记模糊日志）。常见翻车点是先查用户是否存在、再校验验证码，结果验证码输错也触发了短信通道调用，既浪费资源又暴露业务逻辑。
正确流程：收到请求 → 提取 captcha_id 和 captcha_value → 查 Redis 中该 id 对应的真实值 → 严格比对（建议统一转小写）→ 匹配则删除该 id 缓存并往下走 → 不匹配立即返回 <code>{"code":400,"msg":"验证码错误或已过期"}，不区分具体原因。
- 比对完成后必须立即
DEL或EXPIRE对应的 Redis key，防止重放 - 响应中绝不返回
X-Captcha-Debug: true这类调试头，也不在 HTML 里泄露校验逻辑 - input 的
name别写死成captcha，建议拼接随机前缀如captcha_x9f2a，增加自动化解析成本
容易被忽略的细节：时间戳、大小写、缓存头
这三个点看似琐碎，却是多数轻量级实现被攻破的起点。不是“能显示图+能输+能提交”就安全，而是每个环节都要卡住一次有效交互的生命周期。
-
<img src="/captcha?r=" + Date.now()>比Math.random()更可靠，避免某些低版本 WebView 对浮点数处理异常 - 后端比对时别忽略大小写——用户可能输大写，你存的是小写，但没做转换就直接
===，导致合法输入被拒 - 前端 fetch 获取验证码图片时，如果用 blob 转 URL 渲染到 canvas，绘制完必须调
URL.revokeObjectURL(url)，否则内存泄漏积累几轮就卡死页面
