根本原因是gd库不原生支持utf-8字符串绘制，传入的多字节序列被当单字节处理导致错解；必须改用imagettftext()、确保字符串为纯utf-8、使用绝对字体路径、调用mb_internal_encoding('utf-8')并升级php至8.1+以稳定支持unicode。
PHP验证码字母乱码，根本不是“字体没加载”或“HTTP头漏设”这种表层问题——它大概率是图形库在绘制时把传入的字符串当成了单字节编码处理，而你给的是UTF-8多字节序列，结果每个中文字符被拆成2–3个无效字节，PIL（或GD）拿这些字节去查字体映射表，自然画出乱码、方块甚至崩溃。修复必须从字符串编码源头卡死。
GD库生成验证码时传入字符串被截断或错解
PHP内置GD扩展不原生支持UTF-8字符串绘制。即使你用imagestring()传入"验证"，GD会按字节逐个取值，把é（UTF-8中“验”的首字节）当成拉丁字符渲染，结果就是字母乱码或空白。这不是字体问题，是API语义错配。
- 绝对不要用
imagestring()或imagechar()绘制中文或含非ASCII字符的验证码 - 改用
imagettftext()，且确保传入的字符串是纯UTF-8编码（无BOM、无GBK残留） - 调用前加
mb_internal_encoding('UTF-8')，避免mb_*函数内部转码干扰 - 字体文件路径必须是PHP可读的绝对路径，相对路径在CLI和Web环境下行为不一致
imagettftext()调用时字体路径或字符编码不匹配
imagettftext()本身不校验编码，它只负责把字符串字节流喂给FreeType引擎。如果字体不支持对应Unicode码位，或传入字节序列非法（如截断的UTF-8），就会静默替换为缺失符号（□）或乱码字母。
- 用
file_exists()和is_readable()双重检查字体路径，例如：/var/www/fonts/msyh.ttc，不能是./fonts/msyh.ttf - 确认字体真实支持中文：在Linux下用
fc-list :lang=zh查系统字体；Windows下直接双击打开ttf文件看预览 - 传入文字前强制重编码：
$text = mb_convert_encoding($text, 'UTF-8', 'UTF-8');，消除隐式GBK残留 - 避免用
iconv('UTF-8', 'UTF-8//IGNORE', $text)——//IGNORE会删掉非法字节，导致字符数变少、验证码长度不符
验证码输出环节Content-Type与图像格式冲突
很多人加了header('Content-Type: image/png')就以为万事大吉，但GD生成PNG时若内部字符串处理出错，图像数据本身已损坏，浏览器解析PNG header失败后会尝试用文本方式渲染二进制流——这就解释了为什么你看到一堆字母乱码（其实是PNG文件头+损坏像素数据的原始字节被当作文本打印）。
- 务必在
imagepng()前关闭所有输出缓冲：ob_end_clean()，防止BOM或空格混入PNG流 - 不要在验证码脚本里
echo任何调试信息，哪怕是一行print_r()都会毁掉整个图片 - 用
curl -s -D - http://yoursite.com/captcha.php -o /dev/null检查响应头是否干净，确认只有Content-Type: image/png和Content-Length - 本地测试时，直接访问验证码URL，右键“查看图片”，若显示“无法加载”，说明PNG流已损坏，问题在生成阶段而非浏览器
最易被忽略的一点：GD扩展在不同PHP版本对UTF-8的支持差异极大。PHP 7.4之前，imagettftext()对四字节UTF-8（如emoji）基本不可靠；PHP 8.1+才稳定支持。如果你用的是旧版PHP，别折腾字体路径，直接升级PHP或换用imagick扩展——它对Unicode的处理健壮得多。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
