Canvas验证码不能仅靠前端生成，因其明文可读、逻辑可逆、无服务端校验，易被截屏OCR识别或绕过；必须由后端生成随机码并绑定唯一ID，前端仅负责展示图片和提交用户输入，由后端比对Redis/session中存储的原始值。
Canvas验证码为什么不能只靠前端生成
纯前端用 canvas 画出的验证码，无论多扭曲、加多少噪点，对机器来说都是“明文图像”——攻击者直接读取 canvas.toDataURL() 或截取渲染帧就能拿到原始字符。真正起作用的只有服务端生成的校验逻辑，前端 Canvas 只负责「展示」和「用户输入收集」。
所以第一步必须明确：前端只做两件事——请求一个带唯一 ID 的验证码图片（或 base64），把用户输入连同该 ID 一起提交给后端比对。
常见错误现象：
• 直接在 JS 里写死验证码字符串，如 const code = "AB3X"，再画到 canvas 上
• 用 Math.random() 生成后立即绘制，没传给后端存 session
• 把验证码明文塞进 data-* 属性或隐藏 input 中
如何让 Canvas 正确显示服务端返回的验证码图
最稳妥的方式是服务端返回一张 PNG（或 base64 字符串），前端用 drawImage() 渲染到 canvas 上——这样既避开跨域问题，又不暴露原始文本。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 后端接口如
/api/captcha?r=12345（r防缓存）返回 PNG 二进制流，Content-Type 为image/png - 前端用
fetch()获取 blob，转成URL.createObjectURL()，再创建Image实例 - 等
img.onload触发后，调用ctx.drawImage(img, 0, 0)绘制 - 务必在绘制完成后立刻销毁 blob URL：
URL.revokeObjectURL(url)，避免内存泄漏
不要用 canvas.getContext('2d').fillText() 自己画字符——那等于自己造了个可被 OCR 轻松识别的靶子。
用户输入与后端校验必须绑定唯一会话标识
验证码的防刷能力完全依赖「一次一密」：每个图形对应一个服务端生成的随机字符串，并绑定到用户的 session 或 token 中。前端提交时，必须同时携带这个标识（比如叫 captcha_id）和用户填写的内容（captcha_value）。
关键参数差异：
-
captcha_id：由后端生成（如 UUID），响应头或 JSON body 中返回，前端存入 hidden input 或 JS 变量 -
captcha_value：用户在<input type="text">中填写的内容，大小写敏感与否由后端决定（建议统一转小写比对） - 提交前检查：
if (!captchaId || !captchaValue.trim())，避免空提交
性能影响：ID 不要存在 localStorage 或 cookie 里长期复用；每次刷新/点击「换一张」都应触发新请求并更新 ID 和图像。
Canvas 绘制干扰元素时容易忽略的兼容性陷阱
如果坚持要在前端叠加简单干扰（比如画几条线、点几个噪点），注意这些实际踩坑点：
-
ctx.globalAlpha = 0.3在某些旧版 Safari 下失效，改用rgba(0,0,0,0.3)设 strokeStyle/fillStyle 更稳 - 用
ctx.setLineDash([2, 3])画虚线时，IE 完全不支持，需降级为实线 - 字体必须用系统安全字体族，如
"Arial", "Helvetica", sans-serif，避免自定义 webfont 加载失败导致文字不显示 - 不要依赖
ctx.measureText().width精确计算字符间距——不同浏览器/系统渲染宽度有微小差异，会导致字符挤在一起或断裂
真正需要强度的场景，别碰这些；干扰只是锦上添花，核心防线永远在服务端是否校验了正确 ID + 正确值 + 是否过期 + 单 ID 是否已被使用过。
