网盘项目图形验证码实战：生成、校验与接口防刷

1. 为什么easy网盘要补上图形验证码

1.1 网盘场景里最常被刷的接口是什么

先聊一个现象。很多人在写网盘类项目的时候，习惯把大量精力放在文件上传下载、分片断点、秒传逻辑这些功能上，因为这些功能看起来“有技术含量”。但真正把项目部署到公网、或者开启用户注册之后，你会发现最先出问题的往往不是那些复杂功能，而是最不起眼的注册、登录、发送短信验证码、甚至分享链接的获取接口。

举个我实际遇到的例子：easy网盘早期版本对外开放了用户注册功能，注册接口没有加任何防护。上线第三天，数据库中出现了几万条乱码账号，服务器CPU持续跑满。查日志后发现，是有人用脚本对注册接口做了循环调用。这种请求本身不会直接盗走数据，但它会消耗数据库连接、占用带宽、撑爆存储，把一个教学项目的服务器直接打到不可用。

图形验证码就是为了解决这类问题被补进来的。它本质上是一个门槛，把“机器可以轻松批量执行的操作”变成“必须人类介入才能完成的动作”。在easy网盘这种前后端分离的教学项目中，图形验证码的定位很明确：它不是核心的业务功能，但它是保护核心业务不被刷的基础设施。

1.2 图形验证码要解决什么问题，不解决什么问题

在动手之前，我一直提醒自己：图形验证码不是万能的。它的设计目标非常单一，就是提高自动化脚本的调用成本。一个几行代码写出来的循环脚本可以在毫秒级内请求几百次接口，但有了图形验证码之后，脚本必须先去识别图片中的字符，而这一过程要么需要接入打码平台，要么需要训练OCR模型，成本和复杂度都上去了。

不过要注意，图形验证码能拦的是“无脑刷接口”的场景，而不是“有针对性的人工攻击”。如果对方是一个愿意花时间人工识别验证码的操作者，那它基本拦不住。所以我在easy网盘里的思路是：用图形验证码降低批量注册、批量登录、批量请求分享链接这类行为的自动化程度，把它作为第一道防线。

另外，“图形验证码”这个词里有两个重点，一个是“图形”，一个是“验证码”。图形部分解决的是“人能不能看清楚、机器能不能轻易识别”的平衡问题；验证码部分解决的是“服务端怎么确认用户输入的答案是正确的、并且这个答案只能使用一次”的信任问题。很多人只关注了怎么画出好看的图片，忽略了校验逻辑，结果图片画得再复杂，接口照样能被绕过。这一块我在后面的实现部分会单独展开。

对于easy网盘这个项目阶段来说，补图形验证码还有一个学习层面的考量：它麻雀虽小、五脏俱全。从图片生成、Session存储、接口校验到前端刷新联动，完整覆盖了一个Web功能从后端到前端的闭环。作为补充学习是非常合适的切入点。

2. 方案选择：图形验证码的三条技术路线

2.1 自绘BufferedImage和现成工具类的取舍

真正常见的图形验证码实现方案有几种：第一种是引入现成的开源工具包，比如Java生态里的Hutool的CaptchaUtil、kaptcha等；第二种是自己用BufferedImage在内存中绘制图片；第三种是调用第三方验证码服务。

我给easy网盘做这个模块的时候，没有直接引入Hutool的验证码工具，而是选择了用BufferedImage自己画。主要原因有两个：第一，easy网盘本来就是一个学习性质的项目，自己绘制的过程能帮助理解验证码的生成原理，包括字体、颜色、干扰元素、噪点这些是怎么渲染到图片上的；第二，项目当时的依赖管理非常精简，我不想为了一个验证码功能引入一整套工具库，导致代码体量膨胀。

理论上来说，kaptcha这类成熟方案用的也是类似原理：生成随机字符、绘制图片、把答案存入Session。引入现成库的优点是代码量少、生成效果好、不需要自己关注字符扭曲和噪点算法。缺点是定制起来相对麻烦，尤其是当你想调整字体库、验证码长度、干扰线数量、过期时间这些参数时，你得去读它的配置项文档。自绘方案则完全灵活，代码也就一二百行，难度并不高。

下面是我在easy网盘里实际使用的绘制方案代码，风格是Java Servlet，适合教学项目直接参考。

java复制public class CaptchaGenerator {

    private static final int WIDTH = 120;
    private static final int HEIGHT = 40;
    private static final int CODE_LENGTH = 4;
    private static final Random RANDOM = new Random();

    private static final char[] CHAR_ARRAY = {
        'A', 'B', 'C', 'D', 'E', 'F', 'H', 'J', 'K', 'L',
        'M', 'N', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W',
        'X', 'Y', 'Z', '2', '3', '4', '5', '6', '7', '8', '9'
    };

    public static String drawCaptcha(BufferedImage image) {
        Graphics2D graphics = image.createGraphics();
        // 抗锯齿设置，保证文字边缘平滑
        graphics.setRenderingHint(RenderingHints.KEY_ANTIALIASING,
                RenderingHints.VALUE_ANTIALIAS_ON);
        // 填充浅色背景
        graphics.setColor(new Color(245, 245, 245));
        graphics.fillRect(0, 0, WIDTH, HEIGHT);

        // 生成随机验证码字符串
        StringBuilder code = new StringBuilder();
        for (int i = 0; i < CODE_LENGTH; i++) {
            code.append(CHAR_ARRAY[RANDOM.nextInt(CHAR_ARRAY.length)]);
        }

        // 逐个字符绘制，每个字符使用随机颜色和旋转角度
        int charWidth = WIDTH / CODE_LENGTH;
        for (int i = 0; i < CODE_LENGTH; i++) {
            graphics.setFont(new Font("Arial", Font.BOLD, 26));
            graphics.setColor(new Color(30 + RANDOM.nextInt(180),
                    30 + RANDOM.nextInt(180),
                    30 + RANDOM.nextInt(180)));

            int angle = RANDOM.nextInt(30) - 15;
            double radian = angle * Math.PI / 180;
            graphics.rotate(radian, i * charWidth + charWidth / 2.0, HEIGHT / 2.0);
            graphics.drawString(String.valueOf(code.charAt(i)),
                    i * charWidth + 5, HEIGHT / 2 + 10);
            graphics.rotate(-radian, i * charWidth + charWidth / 2.0, HEIGHT / 2.0);
        }

        // 添加干扰线，干扰识别的同时保证肉眼可读
        for (int i = 0; i < 8; i++) {
            int x1 = RANDOM.nextInt(WIDTH);
            int y1 = RANDOM.nextInt(HEIGHT);
            int x2 = RANDOM.nextInt(WIDTH);
            int y2 = RANDOM.nextInt(HEIGHT);
            graphics.setColor(new Color(150 + RANDOM.nextInt(100),
                    150 + RANDOM.nextInt(100),
                    150 + RANDOM.nextInt(100)));
            graphics.drawLine(x1, y1, x2, y2);
        }

        // 添加噪点
        for (int i = 0; i < 50; i++) {
            int x = RANDOM.nextInt(WIDTH);
            int y = RANDOM.nextInt(HEIGHT);
            graphics.setColor(new Color(RANDOM.nextInt(200),
                    RANDOM.nextInt(200),
                    RANDOM.nextInt(200)));
            graphics.drawRect(x, y, 1, 1);
        }

        graphics.dispose();
        return code.toString();
    }
}

在使用这段代码时有一个细节我建议你留意：字符集不要把所有字母和数字都用上，一定要去掉容易混淆的字符。比如数字1和大写字母I、数字0和字母O，这些在图形验证码里几乎无法区分。easy网盘里我保留了数字2到9以及去掉I和O的大写字母，实际体验下来识别率明显提升。

2.2 为什么把验证码答案放在Session而不是Redis

验证码生成之后，答案需要存在某个地方，等用户提交表单时再拿出来比对。常见的存储方案有两个：一个是Session，一个是Redis。

很多网盘系统的登录注册功能本身就是基于Session做的，所以直接把验证码答案放进Session是最顺理成章的选择。流程很简单：用户请求验证码图片时，后端生成随机字符串，把字符串存到当前会话的Session中，同时把图片返回给前端。用户提交表单时，后端从Session中取出答案，和用户提交的输入做比对，无论对错都清除Session中的验证码。

有人可能会问：如果用Redis存，不是更好吗？因为Redis有键过期机制，可以方便地做到“5分钟过期”，而Session还得自己记录生成时间然后手动判断。对于高并发分布式系统来说，Session还有多节点共享的问题，Redis存储确实更符合集群环境。

但easy网盘只是个单体教学项目，引入Redis意味着还要维护一套Redis服务，项目复杂度就上去了。对于一个登录接口来说，同一用户在极短时间内的请求数量非常有限，Session方案完全够用。而且Servlet容器对Session本身就有空闲超时管理，验证码答案最多也就是在Session生命周期内有效，不会长期占用内存。

我个人的建议是：如果你是在做单体项目，优先用Session；如果你在做微服务集群或者需要多个后端节点负载均衡，再考虑用Redis集中管理验证码答案。为了easy网盘后续能平滑演进，我当时在封装验证码工具类的时候，预留了存储接口，而不是把Session操作直接写死在生成逻辑里，这样以后想换存储方案只需要改实现类。

2.3 核心设计：验证码的“一次性”失效策略

这里要特别强调一个很多初学者容易忽略的问题：验证码必须在校验完成后立即失效，无论校验结果是对是错。

什么叫无论对错都要立即失效？举例说明：用户A请求了一个验证码，答案是“AB3D”。用户A输入错误答案“AB3E”，提交后校验失败。如果服务端不清除旧验证码，用户A可以继续在原答案“AB3D”上不断猜测第四位的正确值，本质上变成了一次暴力破解机会。反过来，如果输入正确，但服务端不把验证码置为已使用，那同一个验证码就可以被反复使用，这也违背了验证码防刷的初衷。

在easy网盘的实现中，我是这样处理的：每次从Session中取出答案进行比对之后，无论成功还是失败，都立即执行session.removeAttribute("captchaCode")。另外在生成新验证码时也先执行一次remove操作，这样不会因为用户连续多次请求图片而产生多个未使用答案堆积在Session里。

对于“有效期”这个维度，则通过记录生成时间戳来实现。Session里存的不只是验证码字符串，还有一个包含时间和答案的简单对象，这样在比对之前可以先检查是否超过了设定的有效期。easy网盘里设置的默认有效期是5分钟，超过5分钟无论答案对不对，都统一提示“验证码已过期”。

过期时间也不是越长越好。太短了用户还没输完就失效，体验很差；太长了给攻击者的爆破时间窗口太大。5分钟在日常使用中是一个比较合理的折中值。

3. 后端接口落地：生成、存储、校验一条链

3.1 完整的验证码接口代码示例

验证码在easy网盘中对应两个后端接口：获取验证码图片的接口和处理登录/注册表单的接口。先来看获取验证码图片的接口实现。

java复制@WebServlet("/api/captcha")
public class CaptchaServlet extends HttpServlet {

    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response)
            throws IOException {

        // 每次都先清除旧验证码，避免Session中堆积
        HttpSession session = request.getSession();
        session.removeAttribute("captchaCode");
        session.removeAttribute("captchaTime");

        // 创建空白图片
        BufferedImage image = new BufferedImage(120, 40, BufferedImage.TYPE_INT_RGB);

        // 绘制验证码并返回答案
        String code = CaptchaGenerator.drawCaptcha(image);

        // 存储验证码答案和时间戳
        session.setAttribute("captchaCode", code);
        session.setAttribute("captchaTime", System.currentTimeMillis());

        // 设置响应类型为PNG图片
        response.setContentType("image/png");
        response.setHeader("Cache-Control", "no-store");
        response.setHeader("Pragma", "no-cache");
        response.setDateHeader("Expires", 0);

        // 输出图片字节流
        ImageIO.write(image, "png", response.getOutputStream());
    }
}

这段代码里有一个细节值得单独讲：缓存控制头。验证码图片数据属于敏感信息，如果浏览器或者CDN对它做了缓存，用户很可能看到一张过期的图片。所以接口中显式设置了Cache-Control为no-store，禁用所有缓存。如果你使用的是Nginx反代，还需要确认Nginx层没有对图片路径做强制缓存。

3.2 登录注册接口里如何校验验证码

easy网盘的登录接口原本只接收用户名和密码，补上验证码之后会额外接收一个code字段。校验逻辑放在用户密码校验之前，顺序不能反。原因很直接：如果先验证用户名密码，攻击者可以直接通过错误密码和错误验证码的组合来观察响应差异，间接探测某个账号是否存在。把验证码校验放在最前面，可以让脚本连“试探账号是否存在”的步骤都做不到。

java复制String inputCode = request.getParameter("code");
HttpSession session = request.getSession();

if (inputCode == null || inputCode.trim().isEmpty()) {
    response.setStatus(400);
    response.getWriter().write("验证码不能为空");
    return;
}

Object captchaObj = session.getAttribute("captchaCode");
if (captchaObj == null) {
    response.setStatus(400);
    response.getWriter().write("请先获取验证码");
    return;
}

// 判断验证码是否超过5分钟
Long captchaTime = (Long) session.getAttribute("captchaTime");
if (captchaTime == null ||
        System.currentTimeMillis() - captchaTime > 5 * 60 * 1000) {
    session.removeAttribute("captchaCode");
    session.removeAttribute("captchaTime");
    response.setStatus(400);
    response.getWriter().write("验证码已过期，请刷新后重试");
    return;
}

// 比对答案，无论成功失败都删除旧验证码
String storedCode = (String) captchaObj;
session.removeAttribute("captchaCode");
session.removeAttribute("captchaTime");

if (!storedCode.equalsIgnoreCase(inputCode.trim())) {
    response.setStatus(400);
    response.getWriter().write("验证码错误");
    return;
}

// 验证码校验通过，继续执行用户名密码校验逻辑

校验过程中我统一使用了equalsIgnoreCase方法，忽略大小写。很多图形验证码的字符有大小写混合的情况，如果要求用户必须严格区分大小写，识别难度会上升很多，实际意义有限。在不区分大小写的前提下，生成时只需要统一用大写字母，校验时用忽略大小写的比较就能满足需求。

3.3 请求验证码的Session机制和跨域问题

easy网盘是前后端分离结构，前端页面可能部署在8080端口，后端接口在9090端口。这种情况下，浏览器侧会出现一个经典问题：请求验证码图片接口的时候，浏览器是否会自动携带登录时创建的Cookie？

这里的关键点是，Cookie是按域名和路径存储的，端口差异不会影响Cookie的携带，但跨域请求会。如果前端页面是从http://localhost:8080发起请求到http://localhost:9090，这个请求属于跨域请求。浏览器是否在跨域请求中携带Cookie，取决于后端接口跨域配置中是否设置了Access-Control-Allow-Credentials为true。

easy网盘里我处理跨域时，把allowedOrigins从星号改成了具体的页面来源地址，并且打开了allowCredentials。只允许具体来源而不是星号，是因为带Cookie的请求不能使用通配符来源。如果这里没有配置好，最常见的现象就是：图片能正常显示，但是每次提交表单都提示“请先获取验证码”，因为后端每次拿到的Session都是新的。

在实际排查的时候，我建议先从浏览器开发者工具里看“请求头”里是否携带了Cookie。没有Cookie的请求，说明前端到后端的会话链路就没打通，这时候不管后端代码写得对不对，验证码都不可能校验通过。

4. 前端配套逻辑：展示、点击刷新、整体联动

4.1 图片加载与点击刷新的实现

图形验证码接口返回的是一张图片，前端使用img标签就能直接展示。easy网盘页面上我用了一个div包住img，并在img下面加了一个“看不清？换一张”的提示文字，点击后重新请求验证码接口。

最直接的刷新方式是把img标签的src重新赋值一遍：

javascript复制const captchaImg = document.getElementById('captchaImg');

function refreshCaptcha() {
    // 加时间戳参数，避免浏览器命中缓存
    captchaImg.src = '/api/captcha?t=' + Date.now();
}

captchaImg.addEventListener('click', refreshCaptcha);

有经验的朋友可能已经看出来了，这里时间戳参数的作用其实不一定有效，因为后端返回头里已经设置了no-store，浏览器正常情况下不会缓存验证码图片。但保留时间戳参数仍然是个好习惯：一方面它明确告诉浏览器“这是一个新请求”，另一方面在调试代理工具里也能方便地分辨多次请求。即使后端将来改了缓存策略，前端也能保证图片刷新真的触发了网络请求。

另外要注意一点：easy网盘的验证码图片生成接口是GET请求，因为img标签天然支持GET。但登录和注册的表单提交是POST请求。两个接口的验证码状态是共享的，因为Session机制以用户会话为基础，不区分是GET还是POST。

4.2 与登录表单的联动校验

前端在用户提交登录表单时，需要把验证码输入框的内容一并提交。easy网盘的登录表单在提交前会做一层前端校验，重点有三个：

第一个是验证码输入框非空校验。很多用户会忽略验证码，直接输入账号密码就点登录。与其等待后端返回“验证码不能为空”这样的错误提示，不如在提交前就拦截下来。easy网盘里在登录按钮的click处理函数中判断了验证码输入框的value是否为空，为空则在表单上显示出提示文案。

第二个是登录失败后自动刷新验证码。这个细节是实际使用中总结出来的。如果用户提交登录后发现密码错了或者验证码错了，此时旧的验证码已经失效，必须自动刷新图片，否则用户会因为“看不清”或者“已经过期”再次提交失败。easy网盘的登录逻辑在收到任何非200响应后，都会调用refreshCaptcha函数，保证用户下次看到的是一张新图。

第三个是登录成功后不需要主动刷新验证码。因为登录成功会跳转到文件管理页面，验证码状态对后续操作不影响，不需要额外处理。

如果你在做注册表单，前端校验逻辑还要更复杂一点：用户名、密码、确认密码、验证码都不能为空，并且两次密码要一致。easy网盘里注册和登录共用同一个验证码接口和同一套刷新逻辑，只是提交的目标URL不同。

4.3 前后端联调的几个判断手段

前后端联调是这个模块最耗时也最容易出问题的阶段。我在给easy网盘做验证码模块时总结了一个判断流程，按顺序执行能快速定位问题所在：

第一步，打开浏览器开发者工具的Network面板，找到验证码图片的请求。如果请求返回200并且响应内容是一个图片，说明后端图片生成和Session存储没有大问题。如果返回403或者404，优先检查接口路径是否匹配、是否有权限拦截器把图片接口拦掉了。easy网盘里有一个登录鉴权的拦截器，初期忘了在放行列表里加上/api/captcha，结果导致验证码图片接口根本访问不到。

第二步，当图片能正常显示后，找到登录接口的请求，查看请求头里的Cookie值。如果请求头中看不到Cookie，说明前端XHR请求没有开启withCredentials选项。原生XMLHttpRequest中需要在发送请求前设置xhr.withCredentials = true；fetch请求中需要设置credentials: 'include'。这是前后端分离项目中最常见的跨域问题来源。

第三步，直接复制请求头中的JSESSIONID，再到验证码接口Response Header中查看Set-Cookie的值。如果两者不一致，说明Cookie的路径或域名设置有问题。

这三个步骤走一遍，90%以上的验证码问题都能定位清楚。剩下的问题基本集中在代码逻辑层面，比如Session中保存的验证码被其他地方覆盖了、校验时取错了参数名，这些再配合后端日志就能解决。

5. 我踩过的坑和排查技巧实录

5.1 常见问题速查表

验证码功能做到后期，我积累了一张问题对照表，按照“现象、原因、解决办法”三个维度整理，这里直接分享出来。

这张表里的问题我几乎都遇到过。其中“提示请先获取验证码”出现的频率最高，原因不是后端逻辑写错了，而是前端请求根本带不上Cookie。一查发现是前端部署在localhost:8080、后端在localhost:9090，代理没配置好，所有请求都是跨域状态，后端返回的Set-Cookie被浏览器拦截了。后来我用Nginx把前后端端口统一到一个域名下，前后端路径用/api前缀区分，这个问题就再也没有发生过。

5.2 实战排查思路：用户说“验证码明明是对的”

有一次我在easy网盘测试环境中收到一个反馈，说验证码怎么看都对，但提交后后端一直提示错误。我一开始也以为只是用户输入了容易混淆的字符，后来自己用浏览器完整走了一遍流程，发现竟然复现了。

排查过程是这样的：我先在后端日志里打印了用户提交的验证码值和Session中保存的值，发现两个值确实不同。然后我刷新了几次页面，观察变化规律。最终定位到问题是参数名不一致：前端提交的字段名是verificationCode，后端获取时用的是request.getParameter("code")，拿到的自然是null。

这种问题在联调阶段很典型，纯看后端代码或者纯看前端代码都发现不了，只有把两端对齐才能看出来。easy网盘里定义的统一字段名是code，前端提交时也把参数命名为code，之后把前端页面和接口文档里的字段名核对了一遍，问题解决。

另一个类似案例是验证码图片能显示，但用户肉眼看到的字符和老后端生成的字符串不一致。原因是后端生成时用的随机字符集中包含了小写字母，但页面显示时字体渲染得不够清晰，小写字母l和大写字母I根本分辨不出来。修复方式就是我前面讲的，移除容易混淆的字符。

5.3 补充建议：防刷还是要多层配合

图形验证码在easy网盘里属于第一道防线，但只靠一个验证码并不能完全防住所有刷接口的行为。我在项目里还配合了其他几个策略：

限制单个IP的访问频率是值得做的。easy网盘在Nginx层加了简单的limit_req配置，对登录接口和注册接口的请求频率做了限制。假设合法用户最多每3秒请求一次登录接口，超过这个频率的请求直接返回503。这样即使攻击者绕过了验证码识别，也无法在短时间内发起大规模爆破。

同一个账号的连续失败次数限制也值得加。easy网盘里对某个用户名连续登录失败5次后，会锁定该账号15分钟，锁定期间即使密码和验证码都正确也不允许登录，避免攻击者对单一账号做密码字典攻击。这个策略能有效防止撞库行为。

体验上还有一个细节：接口校验错误次数多了以后，可以逐步增加验证码的复杂度，比如从纯数字4位升级到字母数字混合5位。easy网盘里暂时没有做动态复杂度，但如果项目面向公网开放，这是一个可以考虑的演进方向。

最后是验证码答案的传输问题。如果整个表单走的是HTTPS，那验证码答案和密码一样都是加密传输，安全性没有问题。如果项目还在用HTTP，验证码答案和账号密码都可能被中间人截获，这种情况下验证码本身能防的不是专业攻击者，而是最基础的批量脚本。所以如果你准备把easy网盘部署到公网，第一件事应该是配置HTTPS证书，然后再考虑验证码的复杂度设计。

写在最后的小技巧

图形验证码虽然是一个很小的模块，但它把图片生成、会话管理、前后端联动、接口防护这些知识串在了一起。我自己的体会是：刚写完easy网盘的文件上传下载功能时，反而是在补这个验证码模块的过程中，才真正理解了Session的跨请求工作机制。建议读到这里的你，也尝试把验证码从4位改成6位、把噪点数量增加几档、再加入算术运算或者滑块验证码，慢慢体会不同方案之间的平衡感。自己动手改一版，比看十篇文章都管用。