验证码这玩意儿前端做起来最烦人的不是生成随机数而是怎么让用户觉得“这验证码靠谱”但又不会难到让人摔键盘。最近在做一个某企业内部系统的登录改造需要在纯前端环境里重新实现验证码的刷新逻辑抽空把这个基础功能完整拆了一遍从随机数的底层逻辑到canvas绘制的抗锯齿细节都整理出来了。先说结论这个功能本身不复杂核心就两件事——生成随机验证码点击刷新。但“生成”这两个字背后藏着不少坑比如随机数够不够随机、字符要不要去掉容易混淆的、生成的验证码能不能被OCR轻易识别、刷新按钮的点击事件有没有绑定稳。这篇文章会把整个实现过程、踩坑记录和最终可直接抄作业的代码全部放出来。1. 整体设计与思路拆解1.1 这个验证码到底要解决什么问题先抛开代码聊聊业务场景。验证码出现的核心目的是区分“人”和“机器”防止批量注册、暴力破解、恶意刷接口这类操作。纯前端的验证码严格来说安全性有限因为它没法验证“生成验证码”这个动作是发生在用户本地还是被攻击者绕过了。但很多内部系统、低风险场景下前端验证码配合后端的校验逻辑已经足够拦住大部分无脑脚本。这个需求里有两个关键词需要注意初始生成和点击刷新。这两点决定了验证码的状态管理方式——每次生成都是一次全新替换旧验证码立即失效不能出现“刷新了但内容没变”的尴尬情况。这涉及随机函数的调用时机和DOM的重绘逻辑。1.2 为什么技术选型定为原生JavaScript网上随便一搜验证码生成方案一大堆什么jQuery插件、Canvas库封装的甚至还有后端接口直接返回图片的。但这次的需求环境很明确一个传统项目里的小模块不打算为此引入额外依赖要求轻量、可维护、容易改样式。所以选型直接定为原生JavaScript Canvas。为什么不选后端生成原因有三个前端生成的验证码不需要额外接口请求省一次网络往返降低服务端压力。样式调整非常灵活后端生成图片改个颜色都得重新出图。对于“内部系统”这种量级的场景前端验证码完全够用。我见过不少团队把这个简单功能做成后端接口返回base64图片结果每次刷新都要等网络、还要处理缓存问题。没必要。1.3 整体结构规划代码层面分成三个模块验证码生成模块负责生成随机字符组合。绘制模块负责把字符画到Canvas上加干扰线和噪点。事件绑定模块负责绑定刷新按钮的点击事件和初始化调用。这三个模块各干各的互不干扰。后续如果想加倒计时、换成滑块验证、增加后端校验只需要替换对应模块不影响其他部分的正常运行。2. 核心细节解析与实操要点2.1 随机字符串的生成及其隐含问题随机验证码最基础的一层是生成随机字符串。大多数人第一版代码长这样function generateCode() { var chars ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789; var code ; for (var i 0; i 4; i) { code chars.charAt(Math.floor(Math.random() * chars.length)); } return code; }这样写功能上没问题但细抠起来有讲究。字符池的设计上面的字符池把大小写字母和数字全放一起了总共62个字符。实际使用中字母“O”和数字“0”、“I”和数字“1”、“l”和“Z”极其容易混淆。设计验证码时一般有两种处理思路不加区分全保留——用户输错了就重新输入反正验证码本来就是要让人多花点时间剔除易混淆字符——提升用户体验减少无意义的校验失败。我的建议是剔除容易混淆的字符尤其是做成后台校验时用户输错一次就多一次请求体验和服务器压力都不划算。剔除后的字符池我一般这样写var chars ABCDEFGHJKLMNPQRSTUVWXYZabcdefghjkmnpqrstuvwxyz23456789;去掉的原因是O、0、I、1、l、Z这六个看着实在是太像了在部分字体下几乎无法区分。随机数的强度问题Math.random()生成的是伪随机数对于验证码场景足够使用但如果做安全等级较高的登录保护建议用Crypto.getRandomValues()。这里给个简单对比方案随机强度适用场景Math.random()低可预测性强一般表单、低风险验证码crypto.getRandomValues()高密码学安全登录、支付等高安全场景验证码本身会通过后端校验前端用Math.random()问题不大。但如果有人要拿这个代码做支付级别的验证记得换成crypto.getRandomValues()。2.2 绘制方式的选型Canvas vs DOM拼接验证码画出来有两种常见做法。一种是纯DOM拼接每个字符用一个span标签包起来通过CSS设置不同的旋转角度、颜色、间距做出歪歪扭扭的效果。这种方式优点是DOM结构直观方便做无障碍适配缺点是样式容易被用户或脚本直接解析安全性差一些。另一种是Canvas绘制所有字符画在同一块画布上输出成一个图片脚本拿到的是像素数据而不是可解析的文字节点被自动识别的难度更高。这也是目前主流前端验证码的做法。我用的方案是Canvas绘制因为验证码存在的意义就是防止机器识别如果做成DOM节点等于把正确答案写在 HTML 里绕过思路就太多了。2.3 Canvas绘制细节为什么直接画会模糊Canvas绘制的第一个坑是模糊问题。很多初学者直接把Canvas的宽高设置成CSS显示的尺寸比如宽度100px然后画出来的文字边缘发虚看起来像打了马赛克。原因很简单Canvas的绘图缓冲区大小和CSS显示大小不对应。设备像素比DPRDevice Pixel Ratio大于1的屏幕上CSS的1px实际对应多个物理像素。如果不在Canvas内部做缩放处理绘制结果会被浏览器强行拉伸造成模糊。解决办法是动态调整Canvas的实际像素尺寸function setupCanvas(canvas) { var dpr window.devicePixelRatio || 1; var rect canvas.getBoundingClientRect(); canvas.width rect.width * dpr; canvas.height rect.height * dpr; var ctx canvas.getContext(2d); ctx.scale(dpr, dpr); return ctx; }这里先把Canvas的绘图缓冲区放大到物理像素级别再通过ctx.scale(dpr, dpr)保证绘图的坐标系仍然以CSS像素为单位。这样画出来的文字才够锐利。实测下来不处理DPR时验证码在小屏设备上明显发虚处理之后清晰度提升非常明显。如果你在写项目这一步建议一开始就加上不然后面回头改代码Canvas的内容清空重画时还要再调一遍。2.4 干扰线和噪点到底加多少合适干扰线和噪点是验证码防机器识别的关键手段。但这里有个非常实际的矛盾干扰越多机器越难识别但人也越难看清楚。很多系统刚上线时验证码难到用户要刷新好几遍才能看清这种体验是要不得的。我自己常用的参数大致是验证码字符4个4位是体验和安全的平衡点6位太占地方3位太弱干扰线4到6条线条颜色比字符浅避免喧宾夺主噪点50到80个左右密度适中不影响阅读字符旋转角度±30度以内字体大小26到32像素左右取决于画布尺寸干扰线我用的是这类浅色系颜色字符则用深色随机色拉开对比度ctx.strokeStyle rgba(150, 150, 150, 0.5); // 干扰线半透明浅灰色 ctx.fillStyle rgb( randomNum(60, 120) , randomNum(60, 120) , randomNum(60, 120) ); // 字符深色系这样做的好处是用户一眼能看清字符但自动识别程序在提取文字时会被干扰线和噪点干扰不是那么轻易就能识别出来的。3. 实操过程与核心环节实现3.1 接口设计和一个可直接参考的模块结构讲完思路直接上实现。整个模块我用一个立即执行函数包起来对外暴露init方法避免污染全局命名空间(function(global) { use strict; var Captcha { canvas: null, ctx: null, code: , chars: ABCDEFGHJKLMNPQRSTUVWXYZabcdefghjkmnpqrstuvwxyz23456789, init: function(canvasEl, refreshBtn) { this.canvas canvasEl; this.ctx this.canvas.getContext(2d); this.refreshBtn refreshBtn; this.bindEvents(); this.draw(); }, randomNum: function(min, max) { return Math.floor(Math.random() * (max - min 1)) min; }, generateCode: function() { var len 4; var code ; for (var i 0; i len; i) { code this.chars.charAt(this.randomNum(0, this.chars.length - 1)); } return code; }, draw: function() { var ctx this.ctx; var width this.canvas.width; var height this.canvas.height; // 如果还没有设置过尺寸使用CSS尺寸初始化 if (width 0 || height 0) { width this.canvas.clientWidth; height this.canvas.clientHeight; this.canvas.width width; this.canvas.height height; } // 生成新验证码 this.code this.generateCode(); // 清空画布 ctx.clearRect(0, 0, width, height); // 背景色 ctx.fillStyle rgb( this.randomNum(240, 250) , this.randomNum(240, 250) , this.randomNum(240, 250) ); ctx.fillRect(0, 0, width, height); // 画干扰线 for (var i 0; i 6; i) { ctx.strokeStyle rgba( this.randomNum(100, 180) , this.randomNum(100, 180) , this.randomNum(100, 180) ,0.6); ctx.beginPath(); ctx.moveTo(this.randomNum(0, width), this.randomNum(0, height)); ctx.lineTo(this.randomNum(0, width), this.randomNum(0, height)); ctx.stroke(); } // 画验证码字符 var charArr this.code.split(); var charWidth width / charArr.length; for (var j 0; j charArr.length; j) { var fontSize this.randomNum(24, 30); ctx.font bold fontSize px Arial; ctx.fillStyle rgb( this.randomNum(50, 130) , this.randomNum(50, 130) , this.randomNum(50, 130) ); var angle this.randomNum(-30, 30) * Math.PI / 180; ctx.save(); ctx.translate(charWidth * j charWidth / 2, height / 2); ctx.rotate(angle); ctx.fillText(charArr[j], -fontSize / 3, fontSize / 3); ctx.restore(); } // 画噪点 for (var k 0; k 60; k) { ctx.fillStyle rgba( this.randomNum(0, 255) , this.randomNum(0, 255) , this.randomNum(0, 255) ,0.4); ctx.beginPath(); ctx.arc(this.randomNum(0, width), this.randomNum(0, height), 1, 0, 2 * Math.PI); ctx.fill(); } }, bindEvents: function() { var self this; this.refreshBtn.addEventListener(click, function() { self.draw(); }); }, getCode: function() { return this.code; } }; global.Captcha Captcha; })(window);调用方式非常干净var captcha Captcha.init(document.getElementById(captchaCanvas), document.getElementById(refreshBtn));这个模块设计里有个容易被忽略的细节draw()方法一开始会自动读取Canvas的clientWidth和clientHeight作为画布尺寸。这个设计是为了适配CSS里已经写好的尺寸让Canvas自身尺寸和显示尺寸保持一致避免画布拉伸变形。3.2 Canvas宽高为什么要单独理清楚很多项目里验证码绘制模糊的根源就是Canvas宽高设置不对。用上面的代码时建议在CSS里固定Canvas的宽高比如#captchaCanvas { width: 120px; height: 40px; cursor: pointer; }然后通过clientWidth和clientHeight一次性赋值给Canvas的width和height属性。这里区别要搞清楚canvas.width是绘图缓冲区宽度是画布本身的像素量设置它会清空画布内容。CSS的width是显示尺寸控制元素占用的页面空间。如果只设置CSS尺寸而不管canvas.width绘制内容会以默认的300x150像素画布等比缩放到CSS尺寸出现失真或模糊。所以必须让canvas.width至少等于CSS宽度最好再考虑设备像素比。3.3 字体选择与字符间距的避坑经验直接往Canvas上写文字时默认字体的渲染效果经常让人意外。我踩过的坑主要是两个第一字体大小和字符位置不对齐。fillText的第二个参数是字符的x坐标基准但它对齐的是文字的基线不是文字的左边界。如果直接用一个固定的值把所有字符往左排很容易出现字符彼此挤压或者上下跳动。解决方式是在每个字符绘制前用ctx.measureText()量一下实际宽度再动态计算间距。上面的示例代码里我用了一个简化的方式——字符平分宽度后居中偏移效果基本稳定但如果你要精确排版建议用measureText调整。第二中文字体在Canvas上的渲染效果没有英文字体好。验证码通常用英文字母和数字字体建议用Arial或者Verdana不要用默认的sans-serif不同系统下的sans-serif映射到不同字体渲染结果可能差异很大。3.4 点击验证码本身的刷新逻辑需求里明确提出“点击刷新按钮重新刷新随机验证码”不过我在实际项目里发现一个特别自然的补充习惯很多用户会下意识直接点击验证码图片本身去刷新而不是去找那个刷新按钮。所以我在项目里通常也给Canvas加上一个点击事件this.canvas.addEventListener(click, function() { self.draw(); });这个功能不复杂但能明显降低用户的操作成本。如果你在写表单里的验证码建议顺手加上。图片本身就是“可点击刷新”的暗示不需要额外引导。3.5 校验时的注意事项前端的验证码无论生成得多精巧最终都需要和后端配合才能真正起到安全作用。这里我强调一个点前端生成的验证码值必须通过隐藏域或某个前端变量保存在提交表单时一起传给后端校验。不能只在前端做校验否则任何攻击者直接绕过页面校验逻辑或者直接查看前端变量里的验证码值就能通过校验验证码形同虚设。正确的流程是前端生成验证码并把值记录到内存变量在上面的代码里就是this.code。用户提交表单时前端把code一并提交到后端。后端对比前端提交的code和会话中保存的验证码值一致才放行。因为纯前端生成验证码后端不知道验证码是什么所以必须在前端提交时把验证码值一起带过去。后端要做的是校验验证码值格式和是否与会话中已保存的验证码匹配而不是重新生成一个来对比。我给一个简单的校验思路// 提交表单前 var captchaCode captcha.getCode(); if (!captchaCode || captchaCode.length ! 4) { alert(请先刷新验证码); return; } // 把验证码放到表单提交数据中 formData.append(captcha, captchaCode);如果后端还有会话的概念比如登录状态下更稳妥的做法是前端生成后把验证码存到后端会话里再返回给前端绘制但这已经超出纯前端范畴了不做展开。4. 常见问题与排查技巧实录4.1 Canvas内容清不干净字符重叠如果你在调用draw()时没有用clearRect清空画布或者clearRect的尺寸和Canvas实际尺寸不一致就会出现字符残留、新画的文字和旧文字重叠在一起的情况。这看起来像是代码写错了实际上多半是canvas.width和canvas.height设置时没有统一。排查方式在draw()开头打印一下this.canvas.width和this.canvas.height如果和clientWidth、clientHeight不一致说明初始尺寸赋值逻辑没执行。很多时候是因为Canvas在初始化时还没有完成布局拿不到clientWidth比如在DOMContentLoaded之前就调了init。我的建议是在window.onload或DOMContentLoaded之后再初始化document.addEventListener(DOMContentLoaded, function() { Captcha.init(document.getElementById(captchaCanvas), document.getElementById(refreshBtn)); });4.2 刷新验证码时页面被提交了这是一个很经典的坑。用一个button但没写type属性默认就是typesubmit放在表单里点击时会触发表单提交页面刷新看起来就像“验证码刷新了但页面也跟着挂了”。解决方式给按钮显式写typebutton或者事件绑定里调用event.preventDefault()。我自己的习惯是双保险都写上refreshBtn.addEventListener(click, function(event) { if (event) { event.preventDefault(); } self.draw(); });尤其你的刷新按钮如果用的是a标签默认行为是跳转链接更要注意阻止默认行为。4.3 验证码画出来了但用户说看不清这个我在实际使用里遇到了几次原因基本只有一个字符颜色和背景色的对比度太低。有些人会把背景做成亮色而文字做成浅色或者反过来导致验证码形同虚设。最简单的检查方式是截图后转成灰度图如果字符和背景的灰度值差距小于30基本就是对比度不足。我的参数取值原则是背景RGB三个通道都比240大非常浅文字RGB三个通道在40到130之间深色系干扰线允许稍浅但别浅到跟背景一色。用上面的取值范围对比度基本没有问题。4.4 为什么验证码每次刷新内容都和上一次差不多这是因为Math.random()在短时间内大量调用时结果可能呈现一定的规律性。尤其当你在循环里快速生成字符时连续调用Math.random()可能出现相近的随机值序列。解决办法是打乱字符池顺序后再取字符或者增加一次“洗牌”逻辑。在准确性要求没那么高的场景下其实影响不大但真要处理可以简单地在生成前做一次随机偏移var offset this.randomNum(1, this.chars.length - 1); var shuffledChars this.chars.slice(offset) this.chars.slice(0, offset);这样每次取的字符池视角都不同至少在体验上不会出现“刷新一下和上一版几乎一样”的感觉。4.5 移动端触屏点击无反应如果用户反映手机浏览器上点刷新按钮或者点验证码图片没反应首先排查的是事件绑定问题。移动端的点击事件有时会因为300ms延迟或触摸目标过小而失败。处理方式是给刷新按钮和Canvas设置合理的尺寸并绑定touchstart事件作为兼容this.refreshBtn.addEventListener(click, function() { self.draw(); }); this.refreshBtn.addEventListener(touchstart, function(e) { e.preventDefault(); self.draw(); });不过要注意preventDefault会造成click事件不触发所以两个事件都绑定的话实际上只会执行一次不会重复刷新。4.6 代码压缩或打包后出现兼容性问题在传统项目里如果用了压缩工具把这段代码打了包可能出现window对象在非浏览器环境比如Node端做单元测试下找不到的问题。我在模块化改造时会把依赖的window注入到函数内部(function(global) { // 内部所有地方用 global 而不是 window })(typeof window ! undefined ? window : this);这算是一个工程化的小优化在你把代码嵌入到各种环境时能少不少麻烦。5. 排查技巧速查表现象可能原因解决办法验证码模糊Canvas宽高未与CSS尺寸一致init时赋值canvas.width clientWidth字符重叠残留未清空画布或clearRect尺寸不对draw开头执行clearRect(0,0,width,height)点击刷新后页面跳转按钮默认type为submit显式设置typebutton点击刷新没反应事件绑定没生效或元素未渲染完成DOMContentLoaded之后再初始化验证码颜色看不清文字与背景对比度低背景用浅色系文字用深色系验证码每次变化不大Math.random()连续调用不均匀打乱字符池或引入随机偏移移动端点击无效触摸事件未处理增加touchstart事件兼容6. 一点个人经验这个功能做完后我在实际项目中还做过一次小迭代把验证码的过期时间加上了比如生成后60秒内有效超时自动失效并刷新。实现方式很简单在生成验证码时记录一个时间戳提交时判断差值是否超过60秒。如果你要把这个验证码用于登录场景建议一定要加这个过期时间不然验证码会一直有效安全性会打折扣。另外还有一点容易被忽略每次生成验证码后后端会话里保存的值必须同步更新。如果前端刷新了验证码但后端没更新就会出现“验证码明明刷新了但提交时后端还是拿旧的验证码来比对”的问题。这也是纯前端验证码和后端校验配合时要特别注意的一个环节。整体来说前端随机验证码的生成并不是一个复杂的功能但涉及的知识点并不少——随机数生成、Canvas绘制、事件兼容、前后端协作每个环节都有不少细节。对照上面的实现和排查思路你要在项目里落地一个好用又稳的验证码基本不会走弯路。