ThinkPHP 8 默认启用 FormTokenCheck 中间件防 CSRF，自动校验 POST/PUT/DELETE 请求；需确保表单调用 token()、AJAX 携带 token、URL 与生成时一致，且不篡改 session 中的 token 键。
ThinkPHP 8 默认开启 FormTokenCheck 中间件就能防 CSRF
只要没手动关掉，FormTokenCheck 中间件在应用启动时就已加载，所有 POST/PUT/DELETE 请求都会被自动拦截校验。它不依赖你写额外逻辑，也不需要在每个控制器里手动调用验证方法——这是 ThinkPHP 8 的默认行为。
常见错误现象：ValidateException 报错但没看出哪错了；表单提交后直接跳 404 或白屏；开发环境正常、生产环境报 token 无效。
- 检查
config/middleware.php是否误删了think\middleware\FormTokenCheck::class - 确认表单页面是否调用了
token()函数（或{:token()}模板语法），否则隐藏字段压根没生成 - 如果用了 AJAX 提交，不能只传数据不传 token 字段——得手动把
token()的返回值塞进请求体 - 中间件对 GET 请求不校验，所以敏感操作别用 GET 提交（比如删除用
GET /user/delete?id=1就是典型漏洞）
token() 函数生成的值不是随机字符串，而是加密签名
token() 返回的不是纯随机串，而是由会话 ID、当前时间戳、action 名称三者拼接后经 HMAC-SHA256 加密生成的签名。这意味着：同一个用户、同一 action、5 分钟内多次刷新页面，token() 输出可能不变；但换 action 或超时就会变。
这个设计牺牲了一次性，换来了多标签页友好性——用户开两个 tab 编辑同个资源，不会因为先提交一个就导致另一个失效。
立即学习“PHP免费学习笔记（深入）”；
- 不要用
token()的返回值做前端逻辑判断（比如“token 不为空就启用提交按钮”），它本身无业务含义 - 别试图自己解析或修改 token 字符串，框架校验时会完整还原并比对签名
- 如果真要强制每次刷新都换 token，得在模板里加参数：
{:token('edit', true)}，第二个true表示忽略缓存 - 签名有效期由配置项
token_expires控制，默认 300 秒，可改但不建议设太短
FormTokenCheck 校验失败时静默拒绝，不给攻击者反馈
中间件在校验失败时直接抛出 ValidateException，最终响应是 HTTP 400 或重定向到错误页，且响应体里不暴露“是 token 过期”还是“是 token 伪造”。这种设计防止攻击者通过响应差异进行探测。
但这也带来调试困难：前端看不到明确原因，日志里也只记“token 验证失败”，没有上下文。
- 开发阶段可在
app/middleware/FormTokenCheck.php里临时加Log::debug("token fail: ".json_encode($_POST))定位问题 - 确保表单的
actionURL 和生成 token 时的路由一致（比如生成在/admin/user/edit/1，提交却发到/api/user/update，签名必然不匹配） - 禁用浏览器插件（如某些密码管理器）自动填充 hidden 字段，它们可能把旧 token 塞进去
- 如果用了 Nginx 反向代理，确认没丢掉原始 Host 或 Scheme，签名里会参与计算
自定义 token 存储位置会破坏默认防护链
ThinkPHP 的 token 签名机制强依赖会话状态，所有校验逻辑都基于 Session::get('token')。如果你在中间件或控制器里手动覆盖了 $_SESSION['token']，或者用 Redis 替换了默认文件存储但没配好序列化方式，FormTokenCheck 就会读不到原始签名数据。
最常踩的坑是：为了“统一 token 管理”，把 token 存进数据库或 JWT payload，然后自己写验证逻辑——这等于绕过整个框架防护，还容易漏掉时效性、绑定 action、防重放等细节。
- 不要动
think\facade\Session里的 token 相关 key，框架内部硬编码用了__token__这个键名 - 如果必须扩展（比如支持 API 场景），应在中间件里继承
FormTokenCheck并重写getToken()方法，而不是另起炉灶 - 跨域请求（CORS）下，CSRF 防护依然有效，但前提是 Cookie 被携带且 SameSite 属性没被浏览器拦截——别指望靠关掉 token 来解决跨域问题
