ThinkPHP CSRF 令牌需手动启用校验，路由层配置 ['token' => true] 最稳妥；{:token()} 仅用于表单内生成隐藏域，AJAX 需接口获取并手动传入 _token 字段。
ThinkPHP 的 CSRF 令牌默认不生效，token() 或 {:token()} 只是输出一个字段，校验逻辑必须手动启用，否则“非法请求”报错纯属配置遗漏，不是攻击触发的。
路由层启用 token 校验最稳妥
在定义需要防护的路由时，显式加上 ['token' => true] 是最直接、无遗漏的方式。它会自动注入 think\middleware\TokenCheck 中间件，且作用范围清晰可控。
- POST 表单路由必须加，GET 路由不用加（CSRF 只针对状态变更请求）
- 如果用了资源路由（
Route::resource()），需单独为store和update指定规则，资源路由默认不带 token 配置 - 子域名或分组路由中启用，要确认中间件未被覆盖 —— 比如分组里写了
->middleware([])就会清空继承的中间件 - 验证失败时默认返回 400 状态码和“非法请求”文字，不跳转、不抛异常，前端需按此约定处理响应
控制器里用中间件声明容易漏写
在控制器类中通过 protected $middleware = [\think\middleware\TokenCheck::class]; 启用，看似简洁，但极易因继承关系或命名空间错误导致失效。
- 父控制器写了中间件，子控制器没调用
parent::__construct()或覆盖了$middleware，校验就丢了 - 如果控制器方法用
return $this->fetch();渲染页面，但后续 AJAX 提交也走这个控制器，得确保所有入口都经过校验 —— 不然部分请求绕过 - 调试时可在方法开头加
dump($this->app->session->get('__token__'));，确认 session 里真有值，而不是空数组 - 别在构造函数里提前调
input()或读取php://input，否则TokenCheck拿不到__token__字段
{:token()} 必须出现在 form 内部且只调一次
模板中写 {:token()} 是生成隐藏域的唯一正确方式，{:csrf_token()} 在 ThinkPHP 6.x 里根本不存在，会直接报 Undefined function csrf_token。
立即学习“PHP免费学习笔记（深入）”；
- 必须放在
<form>标签内部，且整个页面只能出现一次 —— 多个{:token()}会生成多个_token字段，后端只取第一个，其余被忽略 - 如果表单是 JS 动态插入的（比如 Vue 组件或
$.load()加载），不能依赖模板函数，得用\think\facade\Form::token()或接口返回值手动注入 - 开启模板缓存时，
{:token()}可能被静态化；关闭缓存后每次渲染都刷新 token，用户停留太久再提交必然失败 - URL 带查询参数（如
?tab=2）时，默认 token 会绑定完整 URL，?tab=1和?tab=2视为两个不同 token —— 改用{:token(null, false)}忽略 query 影响
AJAX 提交必须手动传 token 字段
前端用 fetch 或 axios 提交时，{:token()} 不起作用，因为没实际渲染进 DOM，或者渲染了但 JS 没读取。
- 推荐方案：提供一个轻量接口，如
GET /api/token，返回json_encode(['token' => token()])，前端在发送前 fetch 一次并塞进data或headers - 不要把 token 拼进 URL（如
?_token=xxx），会被代理、CDN、日志记录，极不安全 - 不要从
document.cookie读取后拼数据 —— XSS 场景下 token 直接泄露 - 如果用
FormData提交，记得append('_token', tokenValue)，别漏掉字段名必须和后端配置一致（默认是_token）
真正麻烦的不是生成 token，而是 token 生命周期与用户行为的错位：多标签页打开同一页面、浏览器恢复缓存页面、表单长时间未提交……这些都会让 session 里的 token 被新值覆盖，旧值作废。这不是 bug，是设计使然，得靠前端主动刷新或后端允许复用（如 token(null, true, true)）来缓解。
