ThinkPHP CSRF验证失败主因是Token生成、传递、校验三环节错配：表单未正确输出__token__字段、validateToken()调用前输入流被消耗、多标签页导致Token过期、URL参数干扰签名、Session未生效或存储异常。
ThinkPHP报CSRF验证失败，绝大多数情况不是框架坏了，而是Token生成、传递、校验三个环节中至少有一处没对上——尤其是默认行为和实际使用场景错配。
表单里没正确输出__token__字段
模板中写了{:token()}，但页面源码里压根没出现<input type="hidden" name="__token__" value="...">，说明函数没执行或被缓存拦截了。
- ThinkPHP 6.0+ 中
token()必须在View::fetch()前调用；若用了view()->assign()，得先调token()再assign()，否则视图里{:token()}取不到值 - 纯前端渲染（如Vue接管表单）时，
{:token()}无效，必须后端单独提供/api/token接口返回token()结果 - 别手写
<input name="__token__">——漏掉动态更新逻辑，且不兼容URL参数变化
validateToken()调用时机或方式错误
控制器里写了$this->validateToken(input('post.'))，但始终返回false，常见原因是输入流已被提前读取或请求方法不匹配。
- 中间件里如果提前调了
input()（比如日志记录），原始POST数据流会被消耗，后续validateToken()拿不到__token__字段 -
validateToken()默认只处理POST请求，GET提交会直接报错；若需全局校验，务必先判断$this->request->isPost() - 传参别用
input('post.')，改用$this->request->param()——前者可能因input()被多次调用而为空
Token失效太快或跨页冲突
用户刚打开页面就提交，提示“非法请求”；或多标签页操作时，旧页提交必失败——这不是Bug，是ThinkPHP默认一次性Token机制的必然表现。
- 默认每个新页面渲染都会刷新session里的Token，旧页表单仍带旧值，校验自然失败
- 启用复用：V6.1+ 可用
token(null, true, true)（第三个true表示同会话内允许多次验证） - 避免URL参数干扰：若页面带
?tab=2等查询参数，token()默认会把完整URL作为签名依据，导致刷新后校验失败；应显式调用token(null, false)忽略query - 前端可监听
pageshow事件，检测页面是否从缓存恢复，若是则主动fetch('/api/token')刷新隐藏域
Session未生效或存储驱动异常
Token存在session里，session一断，验证铁定失败。但错误现象往往不报session问题，只显示“非法请求”或500。
- 确认配置中
'session' => ['type' => 'file']对应目录可写；若用Redis，检查session.save_path是否指向可用实例，且Redis未满或连接超时 - 跨子域名访问时，
session.cookie_domain必须显式设为.example.com，否则不同域名间session无法共享 - 开发环境开Xdebug或输出缓冲，可能导致
session_start()延迟触发，建议入口文件第一行就调用session_start()（TP6默认已做，但自定义中间件可能覆盖）
真正难排查的是Token签名依赖URL路径+参数+session ID这三者组合，任意一个变动都导致不匹配；而错误信息又极其笼统。与其反复试错，不如在验证前加一行dump($this->request->url(true), session('__token__'), input('__token__'))，三值比对一眼定位断点。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
