验证码问题主因是缓存干扰图像输出或Session数据，需清输出缓冲、禁用响应缓存、显式设置Session时效、前端加时间戳防缓存、确保GD支持PNG且配置正确。
验证码不刷新、输对了还报错，大概率不是逻辑问题，而是缓存干扰了图像输出或 Session 数据。禁用缓存不是关掉整个框架缓存，而是精准切断影响验证码生成与校验的那几处。
验证码图片不刷新？先清输出缓冲
TP5/6 中 captcha_img() 或 Captcha::create() 返回的是原始 PNG/JPEG 二进制流，任何前置输出（空格、BOM、echo、错误提示）都会污染响应，导致图片损坏或浏览器拒绝渲染。
- 在控制器中调用验证码方法前加
ob_clean()，尤其当你在方法里混写了日志、dump()或调试语句时 - 确保入口文件、配置文件、公共函数里没有意外输出（比如 UTF-8 BOM 头）
- 开发期可临时关闭错误显示：
ini_set('display_errors', '0');，避免 Warning 写进图片流
验证码校验总失败？检查 Session 缓存与有效期
验证码靠 Session 存 code，但 Session 本身可能被缓存机制拖慢更新，或因过期策略不一致导致“刚发的码校验不了”。
- 不要依赖默认 Session 过期时间（如 24 小时），而应在生成验证码时显式设置短时效：
session('verify_code', $code, 300)（TP6）或用缓存驱动：cache('verify_' . session_id(), $code, 300) - 确认
session.save_path可写，且 runtime/session 目录有写权限；Linux 下常见权限不足导致 Session 写入静默失败 - TP8 推荐完全绕开 Session，改用带 key 的缓存键：
cache('cap_' . $key, $code, 300)，前端提交时一并传$key，校验时按 key 查，解耦更稳
前端反复加载同一张图？强制绕过浏览器缓存
浏览器对 img src 有强缓存策略，即使后端已更新，前端仍可能复用旧图，造成“点不动”假象。
- 前端绑定点击事件时，必须带唯一参数：
onclick="this.src='/captcha?t='+Date.now()"，不用Math.random()（有重复概率） - 服务端路由返回的验证码响应头需明确禁止缓存：
header('Cache-Control: no-store, no-cache, must-revalidate, max-age=0'); - 若使用 Nginx，检查是否全局加了
expires 1h;，需对/captcha*路径单独禁用：location ^~ /captcha { expires -1; }
TP8 扩展初始化失败？config/captcha.php 缺失会静默报错
TP8 不再自动加载验证码配置，topthink/think-captcha 扩展若找不到 config/captcha.php，会直接抛出 Class 'think\captcha\Captcha' not found，而不是提示配置缺失。
- 手动在
config/目录下创建captcha.php，至少包含基础项：'length' => 4、'useNoise' => true、'bg' => [245, 245, 245] -
'bg'必须是 RGB 数组，写成'#f5f5f5'会导致 GD 绘图失败，无报错、无图片、仅返回空白响应 - GD 扩展必须启用且支持 PNG：
php -r "print_r(gd_info()['png_support']);"输出1才算合格
最易忽略的一点：验证码流程涉及输出控制、Session 状态、前端缓存、GD 能力四层叠加，任一层卡住都表现为“不生效”。排查时别跳步，从 ob_clean() 和 phpinfo() 看 GD 开始，比改一堆配置更省时间。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
