thinkphp 的 _token 是基于会话id、控制器名、操作名、时间戳和密钥加密生成的动态哈希值，由 tokenbuild::build() 生成，经 think\middleware\tokencheck 校验，但仅在路由或控制器显式启用 token 验证时生效。
ThinkPHP 的 _token 是怎么生成和校验的
ThinkPHP 的表单令牌不是随机字符串，而是基于当前会话 ID、控制器名、操作名、时间戳和密钥拼接后加密生成的哈希值，每次请求都会变化。它默认绑定在 session 中，且只对当前会话有效——换浏览器、清 cookie、重启服务都会导致校验失败。
关键点在于：_token 值由 TokenBuild::build() 生成，校验逻辑在 think\middleware\TokenCheck 中触发，但**仅当路由或控制器启用了 token 验证规则时才生效**，不是所有 POST 请求自动拦截。
- 默认不开启全局 token 校验，必须手动配置（如在路由定义中加
['token' => true]或控制器里用protected $middleware = [TokenCheck::class];） -
_token字段名可自定义，但模板中必须和后端配置一致，否则Request::token()拿不到值 - 如果使用 AJAX 提交，
_token必须显式传入，不能依赖表单自动渲染
模板里写 {:token()} 还是 {:csrf_token()}
ThinkPHP 6.x 只认 {:token()}，{:csrf_token()} 是 Laravel 风格，直接写会报错 Undefined function csrf_token。这个函数本质是调用 think\facade\Form::token()，输出形如 <input type="hidden" name="_token" value="xxx"> 的 HTML。
- 必须放在
<form></form>内部，且不能重复调用，否则多个_token字段会导致校验失败 - 如果表单是动态加载的（比如通过 JS 插入），不能靠模板函数，得用
Url::build('token')或直接调Request::token()获取值再塞进去 - 若关闭了模板引擎缓存，
{:token()}每次渲染都生成新值，但页面没刷新前旧表单仍会提交过期 token
POST 提交后提示 “token error” 的常见原因
“token error” 不代表 CSRF 攻击，90% 是开发流程问题。最典型的是：表单渲染后用户停留太久再提交，或者同一账号在多标签页反复打开相同表单页。
- 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 方案，而不是关掉验证。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
