@csrf不能完全防重复提交，因其仅防御CSRF且_token一次性有效但不校验请求唯一性；需结合后端幂等控制（如指纹校验、数据库唯一索引）与前端按钮禁用。
为什么 @csrf 不能完全防重复提交
@csrf 生成的 _token 是一次性有效的，但它的主要作用是防御 CSRF，不是防重复提交。用户快速连点两次“提交”按钮，第一个请求还没返回，第二个请求可能携带了同一个未失效的 token（尤其在无 JS 拦截、无后端状态校验时），照样能通过验证并入库。
真正防重复提交需要「服务端幂等性控制」+「客户端交互约束」双配合：
- 后端：对同一业务逻辑（如创建订单）识别重复请求（用请求指纹 + 短期缓存/数据库唯一约束）
- 前端：按钮点击后立即置灰、禁用，并显示加载态，防止视觉反馈延迟导致误操作
Laravel 中用 session()->has() + session()->forget() 做简易幂等控制
适合轻量场景（如留言、报名表单），不依赖额外中间件或 Redis。核心思路：表单提交成功后，把本次请求的唯一标识（比如 md5($request->ip().$request->userAgent().time())）存入 session，并在处理前检查是否已存在。
示例流程：
- 在控制器方法开头：
if (session()->has('submit_fingerprint') && session('submit_fingerprint') === $fingerprint) { return back()->withErrors(['message' => '请勿重复提交']); } - 验证通过后、写库前：
session(['submit_fingerprint' => $fingerprint]); - 保存成功后：
session()->forget('submit_fingerprint');
注意：$fingerprint 要足够区分不同用户和会话，单纯用时间戳不行；也不建议只靠 IP，NAT 环境下会误伤。
更可靠的方案：用数据库唯一索引 + DB::transaction() 捕获重复异常
这是 Laravel 生产环境最常用的做法——把幂等性交给数据库保证。例如，订单表加联合唯一索引：UNIQUE KEY `user_id_order_at_unique` (`user_id`, `created_at`)（或用业务字段如 order_sn）。
控制器中这样写：
try {
DB::transaction(function () use ($data) {
Order::create($data);
});
} catch (\Illuminate\Database\QueryException $e) {
if ($e->getCode() === '23000') { // MySQL duplicate entry
return back()->withErrors(['message' => '该操作已执行，请勿重复提交']);
}
throw $e;
}
优点是强一致性，缺点是错误码依赖数据库驱动（PostgreSQL 是 23505），且需确保索引字段能真实代表“同一笔业务请求”。
别忘了前端按钮的 disabled 控制，否则后端再严也没用
很多开发者以为加了 @csrf 就万事大吉，结果用户狂点按钮，多个请求并发发出。Laravel 自身不处理这个，必须自己加 JS：
- 表单提交时：
document.querySelector('form').addEventListener('submit', e => { e.target.querySelector('button[type=submit]').disabled = true; }); - 如果用了 Alpine.js 或 Vue，绑定
:disabled="loading"更稳妥 - 禁用按钮后，记得在失败回调里恢复，否则用户无法重试
最易被忽略的是：AJAX 提交后没清空表单或重置按钮状态，用户刷新页面再次提交，又触发一次——这不属于“重复提交”，而是 UX 缺失，但效果一样糟糕。
