AJ-Captcha 本身不慢，性能问题源于 PHP 调用姿势不当：未设超时、未复用连接、未缓存校验结果、频繁无效 verify 请求、重复生成 token 及错误拦截路径。
AJ-Captcha 本身是 Java 后端服务，PHP 只负责发起 HTTP 请求（如 file_get_contents()、curl_exec()）调用其验证接口。所谓“AJ-Captcha 性能慢”，99% 是 PHP 端发起请求时的阻塞、超时、未复用连接或未缓存校验结果导致的——不是验证码组件本身慢，而是你调它的姿势不对。
PHP 调用 AJ-Captcha 接口时超时或卡顿
默认 curl 或 file_get_contents() 没设超时，一旦 AJ-Captcha 服务响应延迟（比如 Redis 连接慢、滑块轨迹分析耗时高），PHP 请求就会卡住，拖垮整个登录流程。
- 必须显式设置超时：
curl_setopt($ch, CURLOPT_TIMEOUT_MS, 1500)（建议 ≤2s，滑块验证本应毫秒级完成） - 禁用 DNS 缓存查找开销：
curl_setopt($ch, CURLOPT_DNS_CACHE_TIMEOUT, 30) - 启用 HTTP/1.1 Keep-Alive：
curl_setopt($ch, CURLOPT_HTTPHEADER, ['Connection: keep-alive'])，避免每次新建 TCP 连接 - 若使用 Guzzle，务必配置
timeout和connect_timeout，并复用Client实例（不要每次 new）
频繁调用 /verify 接口导致 Redis 压力大
AJ-Captcha 的 /verify 接口依赖 Redis 存储滑块 token 和行为特征数据。PHP 端若在表单提交前未做防重复提交（如按钮 disable + 防抖），或后端未校验 token 是否已用过，就会造成大量无效 verify 请求打到 Redis，引发 KEYS 扫描或 DEL 高频操作。
- 前端必须加 loading 状态 + 按钮置灰，防止用户连点
- PHP 后端收到 token 后，先用
GET查 Redis，命中才调/verify；若返回空或已过期，直接拒绝，不发 HTTP 请求 - 确保 AJ-Captcha 的
redis.key-prefix配置合理（如ajcaptcha:prod:），避免和其他业务 key 冲突导致SCAN效率下降 - 检查 Redis 慢日志：
redis-cli --latency和SLOWLOG GET 5，确认是否因 key 过期策略或内存不足引发阻塞
PHP 侧重复生成/校验导致 CPU 白耗
有些开发者把 AJ-Captcha 的前端 JS 初始化和后端 token 校验逻辑写进登录页的主流程，结果每次页面刷新都触发新 token 生成（/getImg）、每次提交都强制走一遍 verify，完全没利用「一次 token 一次验证」的设计本意。
立即学习“PHP免费学习笔记（深入）”；
-
/getImg接口只应在登录表单首次加载时调用一次，token 存入隐藏域或 localStorage，不要放在 form submit handler 里反复请求 - PHP 后端校验逻辑应独立封装，且仅在收到有效 token 和滑动参数时执行；避免在中间件或全局钩子里无条件调用
- 若使用若依（RuoYi）框架，确认
CaptchaFilter没被错误地应用到非登录路径（如静态资源、健康检查接口），造成无谓开销
真正影响体验的从来不是滑块算法多复杂，而是 PHP 没把网络请求当回事——超时不设、连接不复用、token 不缓存、校验不节制。这些地方改几行代码，比调优 Redis 配置或升级服务器硬件见效快得多。
