数据库加unique索引是最可靠的去重方式，orm校验无法防止并发冲突；更新时需用rule::unique()->ignore()排除自身；批量插入应使用upsert()并确保索引存在；前端去重仅为体验优化，不可替代后端与数据库校验。
数据库层面加唯一索引比代码校验更可靠
直接在数据库字段上加 UNIQUE 约束，是 Laravel 去重最稳的方式。ORM 层的校验（比如 unique 规则）只是前置检查，无法防止并发写入时的竞态——两个请求几乎同时通过校验、又同时插入，就重复了。
- 用
php artisan make:migration add_unique_index_to_users_email新建迁移 - 在
up()方法里写：Schema::table('users', function (Blueprint $table) { $table->unique('email'); }); - 执行
php artisan migrate，之后数据库会拒绝重复email插入，并抛出Illuminate\Database\QueryException - 注意：如果该字段已有重复数据，迁移会失败，得先手动清理或用
DB::statement()加IGNORE选项处理
Laravel 的 unique 验证规则怎么避开“自己”
更新场景下，unique:users,email 会把当前模型也当成待校验对象，导致改自己的邮箱都报错。必须显式排除自身 ID。
- 更新时写成：
'email' => 'required|email|unique:users,email,' . $user->id - 更安全的写法（防 ID 为空或字符串注入）：
'email' => ['required', 'email', Rule::unique('users')->ignore($user->id)] - 如果用的是软删除模型，还要加
whereNull('deleted_at')，否则已软删的记录仍会被视为冲突 - 别漏掉表名和字段名大小写——MySQL 默认不区分，但 PostgreSQL 区分，
unique:users,Email在 PG 里查不到索引
批量插入时去重：别用循环 + firstOrCreate
firstOrCreate 每次都查一次再插一次，100 条数据就是 200 次查询，还容易因并发重复插入。真要批量去重，得靠数据库能力。
- 用
upsert()（Laravel 9.2+）：User::upsert($data, ['email'], ['name', 'updated_at']);—— 按email判断存在与否，存在则更新指定字段 - 低版本可用原生语句：
DB::statement("INSERT INTO users (email, name) VALUES (?, ?) ON DUPLICATE KEY UPDATE name = VALUES(name)", [$email, $name]) - 确保对应字段有
UNIQUE索引，否则upsert和ON DUPLICATE KEY都不生效 - MySQL 的
INSERT IGNORE会静默跳过冲突，但不返回影响行数，调试困难；upsert更可控
前端提交前简单去重只是体验优化，不能当真
JS 用 Set 或 filter() 去重表单数组，只能防用户手抖重复点两次提交。网络延迟、绕过 JS 提交、Postman 直接调接口，都能绕过。
- 例如：
const emails = [...new Set(formData.emails)]只是让界面清爽点 - 如果后端没做校验，恶意用户发 100 个相同邮箱，照样进库（除非 DB 有唯一约束兜底）
- 别在 JS 里做复杂逻辑去重（比如忽略大小写、trim 空格），前后端行为不一致会导致“明明填对了却报错”
- 真正要统一规则，得把清洗逻辑（如
strtolower(trim($email))）放在 Model 的setEmailAttribute()或验证器里
