session_start()必须在生成csrf token前调用，否则$_session['csrf_token']无法持久化；token须用random_bytes()生成并存入会话，校验时用hash_equals()防时序攻击，且验证失败须立即终止执行。
PHP 中 session_start() 必须在 Token 生成前调用
CSRF 防护依赖服务端状态，而 PHP 的 $_SESSION 是最常用、最轻量的存储载体。没调用 session_start() 就写 $_SESSION['csrf_token']，值根本不会持久化——表单提交时验证必然失败。
常见错误现象：Undefined index: csrf_token 或每次刷新页面 Token 都变（其实是没存进去，每次都新生成）。
- 必须确保
session_start()出现在脚本最开头（或至少在任何输出、header 发送前） - 不要在包含文件里“悄悄”启动 session，主逻辑文件也要显式调用
- 如果用了 Composer 自动加载或框架路由，检查中间件是否已启 session；没启就自己加
生成 Token 要用 random_bytes()，别用 md5(time()) 或 uniqid()
Token 弱等于开门揖盗。md5(time()) 可被预测，uniqid() 基于微秒+进程 ID，熵极低，自动化工具几秒就能爆破。
正确做法是用密码学安全的随机源：
立即学习“PHP免费学习笔记（深入）”；
- PHP 7+ 直接用
bin2hex(random_bytes(32))（64 字符十六进制字符串） - 避免用
mt_rand()或rand()，它们不是加密安全的 - 生成后立即存入
$_SESSION['csrf_token']，并设为只读（不暴露给 JS 或 URL）
示例：
$token = bin2hex(random_bytes(32));<br>$_SESSION['csrf_token'] = $token;
表单里放隐藏字段 csrf_token，但别漏掉 POST 和 GET 混用场景
很多人只在 POST 表单加 Token，却忽略 GET 请求也能触发状态变更（比如 /delete?id=123）。只要接口有副作用，就必须校验。
使用场景差异：
- HTML 表单：用
<input type="hidden" name="csrf_token" value="<?php echo htmlspecialchars($_SESSION['csrf_token'] ?? ''); ?>"> - AJAX 请求：把 Token 放在请求头（如
X-CSRF-Token），后端从getallheaders()或$_SERVER['HTTP_X_CSRF_TOKEN']读取 - GET 接口：必须把 Token 作为查询参数传（如
?csrf_token=abc123），并在服务端统一验证
注意：htmlspecialchars() 必须加，防止 XSS 破坏隐藏字段结构。
hash_equals() 校验 Token，不用 == 或 ===
直接用 == 比较 Token 会触发“时序攻击”——攻击者通过响应时间差异逐步猜出正确 Token 的每一位。PHP 官方明确要求用恒定时间比较函数。
常见错误现象：本地测试正常，上线后偶发验证失败（尤其当 Token 含非 ASCII 字符或长度不一时）。
- 必须用
hash_equals($_SESSION['csrf_token'] ?? '', $_POST['csrf_token'] ?? '') - 两个参数都不能为空，否则
hash_equals()会警告或返回false - 验证失败时，**立刻 exit 或 throw Exception**，不要继续执行业务逻辑（比如先删数据再校验）
真正容易被忽略的是 Token 生命周期管理：不清理过期 session、不重置登录后旧 Token、不区分多标签页场景——这些不会让防护“失效”，但会让真实用户反复遇到“Token 不匹配”，最后开发者干脆注释掉校验逻辑。
