验证码异常的直接原因是GD扩展缺失或配置错误，需依次检查GD启用状态、TrueType支持、字体文件存在性与权限、session配置及runtime目录权限。
验证码图片空白或报 GD 扩展错误
直接原因是 ThinkPHP 的验证码类依赖 GD 库生成图像，但部署后常因服务器环境缺失或配置异常导致失败。常见现象是返回空响应、显示“无法加载字体”或直接报错 Call to undefined function imagettftext()。
检查点优先级如下：
- 确认 PHP 已启用
gd扩展（运行php -m | grep gd） - 确认 GD 支持 TrueType 字体：执行
php -r "var_dump(gd_info()['FreeType Support']);"，输出必须为bool(true) -
ThinkPHP默认使用的字体路径是think\captcha\assets\font\1.ttf，该文件需存在且 Web 服务器用户（如 www-data 或 nginx）有读取权限 - 若用的是 Docker 或宝塔等环境，注意字体文件可能被挂载覆盖或权限重置，建议用
ls -l检查实际路径下的1.ttf权限是否为644
验证码始终不刷新或提示“验证码错误”
这通常不是前端问题，而是服务端缓存或 session 配置失效。ThinkPHP 的 Captcha 类默认将验证码值写入 session，若 session 未正常启动或存储失败，验证必然失败。
排查重点在 session 初始化环节：
立即学习“PHP免费学习笔记（深入）”；
- 确认
session_start()已被调用（ThinkPHP 通常自动处理，但自定义入口或 CLI 环境下可能遗漏） - 检查
session.save_path对应目录（如/var/lib/php/sessions）是否存在、可写，且磁盘未满 - 若使用 Redis 存储 session，请确认
session.driver配置正确，并且 Redis 连接可达（可临时切回file验证） - 注意 Nginx 的
fastcgi_param PHP_VALUE "session.auto_start=0";类配置会干扰 ThinkPHP 自身 session 控制，应移除
验证码图片模糊、文字粘连或乱码
本质是字体渲染参数与 GD 图像尺寸不匹配。ThinkPHP 的 Captcha 类默认使用固定宽高（130×40），但若字体过大或抗锯齿开启不当，就会挤压变形。
调整方式以最小侵入为准：
- 修改验证码配置中的
fontSize（建议设为16～18）、length（建议 ≤4）、width/height（如150×50） - 禁用干扰线和杂点能显著提升识别率：
useNoise设为false，useCurve设为false - 若仍乱码，说明字体文件本身损坏或编码不兼容，换用系统自带的
DejaVuSans.ttf或arial.ttf并更新配置中fontttf路径 - GD 渲染质量受
imageantialias()影响，但 ThinkPHP 未暴露该开关，不建议自行 patch 类文件
部署后首次访问正常，后续请求验证码变黑块或 500
这是典型的缓存目录权限残留问题。ThinkPHP 在运行时会把编译后的模板、路由、验证码背景图等写入 runtime 目录，若部署时用 root 用户解压或 rsync，会导致子目录属主/权限混乱。
最稳妥的清理动作是：
- 进入项目根目录，执行
rm -rf runtime/*（不要删 runtime 本身） - 确保
runtime目录属组为 Web 服务器用户（如chown -R :www-data runtime），权限设为755 - 检查
runtime下的cache、log、temp子目录是否自动重建；若没有，说明父目录权限不足或 selinux 启用 - Apache 用户注意
AllowOverride All是否开启，否则 .htaccess 中的 rewrite 规则可能让验证码请求误入 index.php 之外的路径
字体文件权限和 runtime 目录状态，是线上环境最常被跳过的两个检查项。改完别急着测，先 ls -l runtime 和 ls -l think/captcha/assets/font/ 看一眼再刷新页面。
