标准做法是用 bin2hex(random_bytes(32)) 生成 token 并存入 session，表单通过隐藏字段输出；验证时须检查存在性、匹配性及未过期，成功后立即销毁。
PHP 生成 CSRF token 的标准做法
用 bin2hex(random_bytes(32)) 生成足够强度的随机字符串，存进 session，并在表单里用隐藏字段输出。别用 md5(time()) 或 uniqid()，它们可预测、无熵、易被爆破。
常见错误现象：token 每次刷新页面都变（导致 POST 失败）、多个表单共用一个 token（并发提交冲突）、token 存在 cookie 里（被 JS 读取后泄露）。
-
random_bytes()是 PHP 7+ 原生安全随机源，mt_rand()和rand()绝对不能用于 token 生成 - token 必须绑定当前用户 session，且建议附加时间戳或一次性标记（如用
$_SESSION['csrf_token'] = ['value' => $token, 'expires' => time() + 3600]） - 生成后立即存入
$_SESSION，不要等表单提交时再生成——否则 GET 页面不带 token，POST 就必然失败
验证 CSRF token 的关键检查点
验证不是“比对字符串相等”就完事。必须同步做三件事：检查 token 是否存在、是否匹配 session 中的值、是否未过期。漏掉任一环，防护就形同虚设。
典型错误场景：只校验 $_POST['csrf_token'] === $_SESSION['csrf_token']，但没 unset session token，导致重放攻击；或没检查 $_POST 是否为空，让空 token 直接通过。
立即学习“PHP免费学习笔记（深入）”；
- 验证前先确认
$_SERVER['REQUEST_METHOD'] === 'POST'，GET 请求无需校验 - 验证成功后立刻用
unset($_SESSION['csrf_token'])销毁 token（防重复提交），若需多表单支持，改用独立 key 如$_SESSION['csrf_token_edit'] - 如果 token 过期，返回 403 状态码并提示“请求已失效”，不要跳转回表单页——那会暴露 token 已失效，给攻击者试探窗口
CSRF token 在表单和 AJAX 中的传法差异
HTML 表单靠隐藏域，AJAX 请求得靠请求头或数据体携带。两者不能混用逻辑，否则前端发了 token、后端却从错误位置读取，直接校验失败。
容易踩的坑：把 token 放在 URL 参数里（被 log 记录、代理缓存）、用 document.cookie 读取后拼进 AJAX 数据（XSS 场景下 token 泄露）、或者在 Vue/React 组件里全局挂载 token 却没随 session 更新。
- 表单中写：
<input type="hidden" name="csrf_token" value="<?php echo htmlspecialchars($_SESSION['csrf_token']['value'] ?? ''); ?>"> - AJAX 请求推荐加 header：
X-CSRF-Token: <?php echo $_SESSION['csrf_token']['value'] ?? ''; ?>，后端从getallheaders()['X-CSRF-Token']读（注意 Apache 可能需要重写 header 名） - 避免在 JS 中硬编码 token，应由 PHP 渲染到
<meta name="csrf-token" content="...">，再由 JS 读取——这样 token 生命周期与 PHP session 一致
为什么 Laravel 的 @csrf 能自动工作而自己写的容易出错
不是因为 Laravel 更“高级”，而是它默认做了你容易忽略的四件事：token 自动续期、session 绑定校验、失败时抛出异常而非静默跳过、以及模板指令自动 escape 输出。你自己实现时，最常漏的是“自动续期”和“异常中断流程”。
比如用户打开表单页后闲置 2 小时，session 过期但页面仍显示旧 token，点击提交就 419；或者校验失败后只是 echo "fail"，没 exit/die，后续代码继续执行，造成越权操作。
- 每次渲染表单前，检查
$_SESSION['csrf_token']['expires'] < time()，过期就重新生成并更新 session - 验证失败必须调用
http_response_code(403); die();，不能只返回 JSON 成功字段 - 别在公共函数里封装“校验 token”，而要放在每个需要防护的入口点显式调用——否则中间件漏掉一个路由，整条链路就崩了
