JavaScript无法直接校验Session，因其为服务端状态；实际流程是JS传递用户输入和captchaId至后端，由后端从Session中取出验证码比对并返回结果，比对后立即清除以防止重放。
JavaScript 本身无法直接访问或校验 Session，因为 Session 是服务端（如 Java Servlet、PHP、Node.js 等）维护的会话状态，存储在服务器内存或 Redis 中，前端 JavaScript 没有读写权限。所谓“JS 中校验 Session”，实际是前端配合后端完成一次完整的校验流程：JS 负责触发请求、传递参数，后端从 Session（或缓存）中取出验证码并比对。
以下是关键逻辑和实操要点：
前端 JS 的角色：传参 + 触发 + 响应处理
- 用户输入验证码后，JS 收集两个必要字段：
- 用户填写的字符串（如
document.getElementById('captchaInput').value） - 对应的验证码标识（如
captchaId或时间戳/随机 token，用于定位服务端存储的原始值）
- 用户填写的字符串（如
- 发起校验请求（通常 POST 到
/api/login或/api/verify-captcha），把这两个值一起提交。 - 接收后端返回的 JSON 结果（如
{ "success": true }或{ "error": "验证码错误" }），再提示用户。
后端才是校验主体：Session 或缓存查值比对
以 Java Servlet 为例：
- 验证码生成时，将随机字符串（如
"K7mX"）存入request.getSession().setAttribute("captcha", "K7mX")，并设置超时（如session.setMaxInactiveInterval(300);→ 5 分钟）。 - 校验时，从 Session 中取出
"captcha"值，与用户提交的值忽略大小写比对（避免AbC1vsabc1误判），比对后立即removeAttribute("captcha")，防止重放。 - 若 Session 已失效、key 不存在、或值不匹配，返回失败。
为什么不能只靠 JS？
- Session ID（如 JSESSIONID Cookie）虽由浏览器自动携带，但 JS 无法读取 Cookie 中的 Session 内容；
- 若尝试用 JS 读取隐藏域或 localStorage 存的验证码（比如后端渲染时写入
<input type="hidden" value="K7mX">），等于把密钥明文暴露，完全丧失安全性； - Canvas 纯前端生成的验证码，字符串直接存在 JS 变量里，审查元素或调试器一眼可见，形同虚设。
安全增强建议
-
每次请求新验证码，必须更新 captchaId：点击刷新时，先请求
/api/captcha获取新captchaId和图片 URL，再替换<img>的src和表单中的隐藏域值； -
服务端强制校验时效性：除比对值外，检查生成时间戳（如存入 Session 时同时存
captchaTime = System.currentTimeMillis()），超时即拒绝； -
限制尝试次数：同一
captchaId或 IP 地址连续失败 3 次，后端可临时封禁或要求重新获取验证码。
不复杂但容易忽略。真正有效的图形验证码，本质是前后端协同的信任链：JS 是信使，Session 是保险柜，后端才是开锁人。
立即学习“Java免费学习笔记（深入）”；
