gd扩展未启用或字体路径错误、字体不支持中文、字符编码非utf-8、gd渲染配置不当是验证码乱码四大主因，需逐一排查。
GD 扩展没启用或字体文件路径错误
PHP 8.5 默认不开启 GD 扩展，而 imagefttext()、imagettftext() 这类函数依赖它。如果验证码图片里全是方块、问号或空白，大概率是 GD 没加载，或者你传给 imagettftext() 的字体路径根本不存在。
- 用
php -m | grep gd或extension_loaded('gd')确认 GD 已启用 - 字体路径必须是绝对路径，相对路径（比如
./font.ttf）在 CLI 或 Web 环境下行为不一致，容易失效 - 推荐用
__DIR__ . '/fonts/simhei.ttf'这种写法，避免路径拼接出错 - Windows 下注意反斜杠转义问题，统一用正斜杠或双反斜杠：
C:/www/font.ttf或C:\www\font.ttf
字体文件本身不支持中文或缺少字符集
很多开源字体（如 DejaVu、Liberation）默认不含中文 glyph，imagettftext() 遇到中文会静默回退到系统默认位图字体——这正是乱码的根源。不是 PHP bug，是字体“没字可画”。
- 别用
arial.ttf、verdana.ttf这类西文字体渲染中文 - 优先选明确标注“支持 GB2312 / UTF-8 中文”的字体，如
simhei.ttf（黑体）、msyh.ttf（微软雅黑）、NotoSansCJKsc-Regular.otf - 用
fontforge或在线工具检查字体是否包含中文 Unicode 区段（U+4E00–U+9FFF），光看文件名没用 - PHP 8.5 对字体解析更严格，旧版能凑合的字体，在 8.5 可能直接报
Warning: imagettftext(): Could not find/open font
字符编码没统一成 UTF-8
验证码文本若从数据库、POST 请求或配置中来，源头是 GBK 或 ISO-8859-1，但 imagettftext() 强制按 UTF-8 解释字节流，结果每个汉字被拆成 2–3 个无效码点，显示为乱码或跳字。
- 生成验证码字符串前，先做
mb_convert_encoding($text, 'UTF-8', 'auto')，别信“我本地没问题” - 如果用
random_int()拼字符，确保所有候选字都在 UTF-8 编码下定义，例如：$chars = 'ABCDEFGHJKLMNPQRSTUVWXYZ23456789';安全，但$chars = '一二三四五'必须确认源文件保存为 UTF-8 无 BOM - Apache/Nginx 不影响图像输出编码，但 PHP 输出头（
header('Content-Type: image/png')）之后不能再输出任何非二进制内容，否则 PNG 头损坏，浏览器显示为乱码图标
GD 渲染时抗锯齿或颜色模式不兼容
PHP 8.5 的 GD 绑定更新了 libgd 版本，某些老写法（比如未初始化背景色、用 imagecolorallocatealpha() 后没设透明度）会导致文字边缘发虚、偏色甚至消失，看着像乱码。
立即学习“PHP免费学习笔记（深入）”；
- 务必在
imagettftext()前调用imagefilledrectangle()清空背景，否则残留像素干扰识别 - 中文文字颜色建议用
imagecolorallocate($img, 0, 0, 0)显式指定，避免依赖imagecolorclosest()的近似匹配 - 禁用抗锯齿：
imageantialias($img, false)，GD 在高 DPI 或缩放场景下开启抗锯齿反而让小字号中文糊成一片 - 最后一定要
imagedestroy($img)，PHP 8.5 内存管理更激进，漏掉这个可能引发后续图像操作失败
真正卡住人的，往往不是某一行代码写错了，而是字体文件权限不对、Web 服务器用户无法读取字体路径、或者开发机和生产机用了不同编码的源文件——这些细节不报错，只默默产出乱码。
