验证码报错暴露逻辑本质是错误未捕获、display_errors未关闭及输出缓冲失控；应禁用display_errors、启用日志、检测GD/字体/session、清空缓冲并严格控制header输出顺序。
PHP 验证码报错时直接暴露逻辑（比如 imagecreatefrompng(): Failed to open stream 或 Cannot modify header information），本质是错误未捕获 + 错误报告未关闭 + 输出缓冲未控制，不是“验证码本身有保密逻辑”可解决的。
关掉 display_errors，但保留日志记录
开发环境开着 display_errors = On 是方便调试，但上线后必须关——否则任何 PHP 错误（包括 GD 扩展缺失、字体文件路径错、session 启动失败）都会直接打在页面上，泄露服务器路径、PHP 版本甚至部分代码结构。
操作建议：
- 在入口脚本（如
captcha.php）开头加：ini_set('display_errors', '0');
ini_set('log_errors', '1');
ini_set('error_log', '/var/log/php-captcha-errors.log'); - 确保 Web 服务器用户（如
www-data）对日志路径有写权限 - 别用
error_reporting(0)全局屏蔽——它会吞掉E_WARNING（比如 GD 函数失败），导致验证码空白却无提示
用 try/catch 包住 GD 和 session 操作
GD 函数（如 imagecreatetruecolor()、imagettftext()）不抛异常，只触发警告；session_start() 失败也只发警告。但这些警告一旦开启 display_errors 就全露出来。
立即学习“PHP免费学习笔记（深入）”；
更稳妥的做法是主动检测关键依赖是否就绪：
- 检查 GD 是否启用：
extension_loaded('gd')，不通过则直接exit或返回空响应头 - 检查字体文件是否存在且可读：
is_readable($font_path)，避免imagettftext(): Invalid font filename报错 - 手动控制 session：
if (session_status() === PHP_SESSION_NONE) { session_start(); }，防止多次session_start()触发警告
输出前清空缓冲并设置正确 header
验证码图像是二进制流，一旦前面有空格、BOM 或 echo 输出，就会触发 Cannot modify header information，且错误信息可能混在图像数据里，导致图片打不开+报错明文泄露。
必须确保：
- 入口文件（
captcha.php）**顶部无空行、无 BOM、无echo/print** - 调用
ob_start()开头，出错时用ob_end_clean()清掉已缓存内容，再输出错误占位图或 500 响应 - 生成图像后，严格按顺序执行：
header('Content-Type: image/png');
header('Cache-Control: no-store, no-cache, must-revalidate, max-age=0');
imagepng($im);
imagedestroy($im);
别把验证逻辑和生成逻辑写在一起
很多人把「生成验证码 + 写入 session + 输出图像」全塞在一个脚本里，出错时难以定位是生成失败还是写 session 失败。更隐蔽的风险是：如果验证码值被错误地 echo 出来（比如调试残留 var_dump($_SESSION['captcha'])），会直接泄露答案。
拆分建议：
-
captcha_gen.php：只负责生成随机字符串、存入$_SESSION['captcha_code']、返回 base64 图像或直接输出 PNG -
captcha_check.php：只接收 POST 参数比对，不碰图像生成 - 所有敏感值（如
$_SESSION['captcha_code']）在比对后立即unset($_SESSION['captcha_code'])，防重放
最常被忽略的一点：GD 函数失败不会中断脚本，但后续 imagepng() 会传入 null 资源，导致空白图像 + 隐性错误——必须对每个 GD 返回值做 is_resource() 判断，而不是只靠 try/catch。
