如何实现Think的表单令牌验证 token标签防CSRF跨站请求伪造机制最佳实践|Duuu笔记

内部，且不能重复调用，否则多个

_token

字段会导致校验失败

如果表单是动态加载的（比如通过 JS 插入），不能靠模板函数，得用

Url::build('token')

或直接调

Request::token()

获取值再塞进去

若关闭了模板引擎缓存，

{:token()}

每次渲染都生成新值，但页面没刷新前旧表单仍会提交过期 token

POST 提交后提示 “token error” 的常见原因

“token error” 不代表 CSRF 攻击，90% 是开发流程问题。最典型的是：表单渲染后用户停留太久再提交，或者同一账号在多标签页反复打开相同表单页。

独响

一个轻笔记+角色扮演的app

下载

“

PHP免费学习笔记（深入）

”；

session 过期或被回收（如

session.gc_maxlifetime

设得太小），导致服务端找不到对应 token 记录

表单用了 GET 方法提交，而 token 校验中间件默认只检查 POST/PUT/DELETE

前端 JS 修改了

_token

字段值但没同步更新 session 存储的原始 hash（比如复制粘贴表单、用 Postman 手动构造请求）

部署在负载均衡环境却没共享 session 存储（如 Redis 未配置），导致生成 token 和校验 token 落在不同服务器上

绕过或禁用

_token

校验的合理场景

某些接口确实不该走 token 校验，比如第三方回调通知、Webhook 接收、或前后端完全分离且 token 由前端统一管理的项目。这时硬塞

_token

反而增加维护成本。

在路由定义中排除特定 URL：

Route::post('notify', 'NotifyController@handle')->withoutMiddleware(TokenCheck::class);

在控制器方法顶部加注解：

#[WithoutMiddleware(TokenCheck::class)]

（TP6.1+）

不要用

ini_set('session.use_cookies', 0)

或删掉

_token

字段来“绕过”，这会让整个验证机制失效，且掩盖真实问题

真正难处理的是 token 和表单生命周期不匹配——比如一个长表单要填 10 分钟，又不想频繁刷新页面，这时候该考虑用定时刷新 token 的 JS 方案，而不是关掉验证。