@csrf 防 CSRF 的关键是服务端通过会话绑定、单次有效和加密令牌校验实现，而非前端 HTML 本身；其失效多因配置错误、AJAX 漏传令牌或误用于 API 路由。
它靠在表单中嵌入一次性、绑定用户会话的隐藏令牌，服务端收到请求时比对这个令牌是否合法且未被重放 —— 不是靠加密或签名防篡改，而是靠“会话绑定 + 单次有效 + 服务端校验”。
为什么 @csrf 生成的
关键不在 HTML 本身，而在 Laravel 的中间件配合机制：
-
@csrf渲染的是当前会话（session_id）关联的、由Encrypter加密过的令牌，该令牌还包含时间戳和随机因子 - 提交时，
VerifyCsrfToken中间件会解密并验证：是否属于当前会话、是否过期（默认 120 分钟）、是否已被使用（Laravel 9+ 启用prune策略后） - 攻击者无法从其他站点读取这个值（同源策略限制），也无法凭空构造一个有效的加密令牌（没密钥、不知会话 ID）
@csrf 和手动写
本质一样，但安全水位不同：
-
@csrf自动调用csrf_token()，确保每次渲染都生成新令牌（除非缓存了视图） - 手写
行为一致；但若写死字符串如value="abc123"，则完全失效 - 若在 AJAX 请求中漏掉
X-CSRF-TOKEN头或_token字段，即使页面有@csrf，接口仍会返回419 Status code 419
哪些场景会让 @csrf 失效或被绕过
不是机制有问题，而是用法或配置踩坑：
- 启用
SESSION_DRIVER=cookie但未设置SESSION_DOMAIN，导致跨子域时会话不共享，令牌校验失败 -
前端用
fetch或axios提交表单却没带_token字段，或忘了设credentials: 'include'传 Cookie - 在 API 路由中误用了
web中间件组（含VerifyCsrfToken），而 API 默认不应校验 CSRF - 自定义了
App\Http\Middleware\VerifyCsrfToken却删掉了$except数组里的必要路径，比如忘记排除/webhook/stripe
真正容易被忽略的是：CSRF 保护只对「状态变更请求」有意义，而它的有效性极度依赖会话生命周期管理 —— 如果你把 session 存在数据库但没配好垃圾回收，或者用 Redis 但 ttl 设得太短，令牌可能提前失效，表现就是用户反复遇到 419。
