ThinkPHP验证码刷新依赖前端URL参数变动触发新请求，服务端无条件生成新图并存入Session；若未加时间戳等唯一参数，浏览器缓存导致“假不刷新”，或Session未启用、ID不匹配、跨域cookie失效等均会导致校验失败。
ThinkPHP验证码刷新靠URL参数变动触发新图片生成
ThinkPHP的验证码本质是每次请求verify()方法时，调用entry()输出一张新图并写入session。它本身不维护“旧图过期”逻辑，刷新完全依赖前端强制发起新请求——只要URL不同，服务端就无条件生成新验证码。
常见错误是直接改src但没加参数，导致浏览器缓存原图，看起来没刷新；或者后端没清旧session值，造成校验时比对的是上一轮的码。
- 必须在img的
src末尾拼接唯一变动参数（如时间戳、Math.random()），例如："/admin/verify?t=1724722440123" - ThinkPHP 6+ 推荐用
{:captcha_img()}助手函数，它默认已内置点击刷新逻辑，但底层仍是拼?t=参数 - ThinkPHP 3.2/5.x 若手动写
img标签，onclick里不能只写this.src += '?'+Math.random()——若原URL已有查询参数，会变成?a=1??0.123，应先replace(/\?.*$/,'')再拼
TP6中captcha_img()刷新行为的隐藏限制
captcha_img()生成的img标签自带onclick事件，点一下就刷新，看似省事。但它有个关键前提：必须确保当前页面已启用Session中间件，且session_start()已执行。否则entry()无法写入$_SESSION['think_captcha']，后续校验永远失败。
容易被忽略的点是：TP6默认关闭Session自动启动，需在app/middleware.php中确认SessionInit::class已注册；若用多应用模式，还要检查对应应用的中间件配置是否生效。
立即学习“PHP免费学习笔记（深入）”；
- 刷新后立刻校验失败？先
var_dump($_SESSION)看think_captcha是否存在，不存在就是Session没起来 -
captcha_img()返回的URL路径是/captcha?id=default&t=xxx，其中id默认为default，校验时Captcha::check($code, 'default')的id必须一致 - 如果自定义了验证码ID（比如
captcha_img('login')），刷新和校验都得用同一个ID，否则session里存的是think_captcha_login，而check()默认查default
手动实现刷新时verify()方法的参数陷阱
很多人把验证码配置写死在verify()方法里，比如固定length => 4，但实际业务中登录页要4位，找回密码页要6位——这时不能靠前端传参动态改配置，因为entry()不接受运行时参数，它只读取实例化时传入的$config。
正确做法是：在控制器里按场景new不同配置的Captcha实例，或统一用一个配置，但把长度等可变项抽到配置文件中，通过Config::get('captcha.login.length')读取。
- TP6中
Captcha构造函数第二个参数是$id，不是配置数组，别误写成new Captcha($config, 'login')——这会导致$id被当成配置，报错Undefined index: useNoise - TP5.x的
\think\captcha\Captcha类，entry()方法内部会调用generate()生成字符串并存session，但如果你重写了generate()却忘了session('captcha_' . $this->id, $code)，刷新后校验必然失败 - 调试时可在
verify()末尾加echo session('captcha_default');，刷新页面看控制台是否输出新字符串，快速定位是前端没发请求，还是后端没生成
为什么点了刷新但后台校验总提示“验证码错误”
90%的情况是前后端验证码ID不匹配或Session未同步。ThinkPHP校验时默认用default作为ID去查session，但如果你的verify()方法里指定了$captcha->id = 'login'，而校验时没传ID，就会查think_captcha_default，自然找不到。
另一个隐蔽问题是跨域或子域名导致session失效。比如前端地址是https://admin.example.com，后端API在https://api.example.com，即使同根域名，Chrome默认不共享session cookie，刷新请求能生成新码，但校验请求的session是空的。
- 检查校验接口是否和验证码接口同域；若必须跨域，后端需设置
session_set_cookie_params(['domain' => '.example.com'])，且前端fetch要带credentials: 'include' - TP6中
Captcha::check()返回false不等于“输错了”，也可能是session里根本没这个key，此时session()->has('think_captcha_default')为false - 不要在验证码校验前调用
session()->clear()或session()->destroy()，有些开发者为了“安全”在登录成功后清session，结果连验证码session也一起清了
