gd扩展未启用会导致imagecreate等函数返回false或静默失败，验证码脚本空白；需通过phpinfo()或php -m确认启用状态，windows启用extension=php_gd2.dll、linux启用extension=gd.so，重启web服务；同时确保脚本无bom、空格等前置输出，header前调用ob_clean()并匹配正确的content-type。
GD 扩展没启用，imagecreate 直接报错或静默失败
验证码脚本一运行就空白，或者浏览器提示“图像因其本身有错无法显示”，大概率是 gd 根本没加载。PHP 不会主动报错，而是让 imagecreate、imagecolorallocate 这些函数返回 false，后续调用直接中断——你看到的只是空响应。
验证方式很简单：
- 新建一个
phpinfo.php，内容只有<?php phpinfo(); ?>，浏览器访问它 - 页面里搜
gd，确认GD Support显示enabled - 命令行执行
php -m | grep -i gd，有输出说明模块已加载
如果没启用：
- Windows 下检查
php.ini是否有extension=php_gd2.dll（注意不是注释掉的状态） - Linux/macOS 下通常是
extension=gd.so，确认路径正确且文件存在 - 改完必须重启 Web 服务（Apache/Nginx + PHP-FPM），否则不生效
header("Content-Type") 前有任意输出，图片流就被污染
这是最隐蔽也最常踩的坑：哪怕开头多一个空格、BOM 头、echo "" 或 var_dump，浏览器收到的就不是纯 PNG 数据，而是混着 HTML 或乱码的垃圾流，必然显示失败。
排查和修复要点：
- 用编辑器打开验证码文件（比如
verify.php），确保第一行是<?php，前面**零字符**（包括不可见的 UTF-8 BOM） - 在
header()调用前加一句if (headers_sent($file, $line)) { die("Headers already sent in $file on line $line"); }，能立刻定位哪行偷偷输出了 - 临时加
ob_clean();在header()之前，可缓解缓冲区残留问题，但只是补救，不能替代源头清理
输出函数和 MIME 类型不匹配，浏览器拒绝渲染
用 imagepng($img) 却发 Content-Type: image/jpeg，或者反过来，浏览器要么显示损坏图标，要么干脆白屏。这不是 PHP 报错，是 HTTP 协议层的不兼容。
对应关系必须严格一致：
-
imagepng()→header("Content-Type: image/png") -
imagejpeg()→header("Content-Type: image/jpeg") -
imagegif()→header("Content-Type: image/gif")
另外建议加上防缓存头，避免旧图被强缓存：
header("Cache-Control: no-store, no-cache, must-revalidate, max-age=0")header("Pragma: no-cache")
字体路径错误或权限不足，imagettftext 静默失败
如果你的验证码用了 TTF 字体（比如加了扭曲效果），imagettftext 对路径极其敏感。相对路径在 CLI 和 Web 环境下行为不同，而 Web 服务器用户（如 www-data）可能无权读取字体文件。
务必用绝对路径，并验证可读性：
- 用
realpath("font.ttf")或file_exists("/var/www/fonts/arial.ttf")检查路径是否真实存在 - 确认字体文件权限为
644，所在目录权限至少为755 - 如果仍失败，先注释掉
imagettftext行，换成imagestring测试基础绘图是否正常
真正难缠的点往往不在 GD 本身，而在输出流的纯净性——任何微小的前置输出、BOM、缓冲残留，都会让整张图报废。别只盯着函数有没有报错，要盯着 HTTP 响应体是不是 100% 纯二进制。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
