laravel 10 与 11 在数据库迁移中对外键约束和唯一索引的语法、类型匹配规则、命名规范及执行机制完全一致，均要求外键字段类型严格匹配、软删除需联合 deleted_at 建唯一索引，且底层 dsl 无变更。
Laravel 10 和 11 在数据库迁移层面对外键约束与唯一索引的写法基本一致，核心语法、字段类型规则、约束行为逻辑均未发生破坏性变更。Laravel 11 并未重构 Schema 构建器，而是延续了 Laravel 10 的成熟设计，重点优化的是底层兼容性（如 PHP 8.3+ 支持、MySQL 8.4 兼容）和开发体验（如更清晰的错误提示），而非迁移 DSL 本身。
下面从三个关键维度说明实际开发中需注意的要点：
外键字段类型必须严格匹配，10 和 11 都一样严
无论是 Laravel 10 还是 11，只要父表主键用 $table->id()（即 bigincrements），子表外键就必须用 foreignId() 或显式声明为 unsignedBigInteger()——不能用 bigInteger()（有符号）、也不能漏掉 ->unsigned()。
否则 MySQL 仍会报 errno 150，且该错误在两个版本中表现完全一致。
✅ 推荐写法（10 & 11 通用）：
-
$table->foreignId('user_id')->constrained()->onDelete('cascade');
❌ 风险写法（两个版本都失败）： -
$table->bigInteger('user_id')->unsigned();（类型不匹配） -
$table->unsignedBigInteger('user_id');（缺->foreign(...)或->constrained()）
唯一索引的语义和实现没变，但软删除场景更需显式处理
$table->string('email')->unique() 在 10 和 11 中行为完全相同：建唯一 B-tree 索引 + 数据库级约束。
但若模型启用了软删除（SoftDeletes），仅对 email 加唯一索引会导致逻辑删除用户后，新用户仍可注册同邮箱。
✅ 正确做法（两版本通用）：
-
$table->unique(['email', 'deleted_at']);
⚠️ 注意：deleted_at字段默认允许 NULL，而 MySQL 中NULL != NULL，所以多列唯一索引天然支持“多个已删除记录共用同一 email”。这是设计使然，不是 bug。
迁移执行机制和约束命名规则保持兼容
- 外键约束名默认仍是
{table}_{column}_foreign（如posts_user_id_foreign） - 唯一索引名默认仍是
{table}_{column}_unique（如users_email_unique） -
php artisan migrate、migrate:rollback、migrate:fresh的行为逻辑未改动 - 删除约束仍用：
-
$table->dropForeign(['user_id']); $table->dropUnique('users_email_unique');
-
不复杂但容易忽略
