重命名表时 foreignid() 自动生成的约束名会失效，需先删除原外键、再重命名表、最后用 foreign() 显式重建并指定新约束名，foreignid() 在此场景下完全不可用。
重命名表时 foreignId() 自动生成的约束名会失效
直接用 Schema::rename() 重命名表后，原表上由 foreignId()->constrained() 创建的外键约束名（如 orders_user_id_foreign）不会自动更新。MySQL 仍按旧表名解析约束，导致后续迁移或删除操作报错：SQLSTATE[HY000]: General error: 1025 Error on rename 或 errno: 150 "Foreign key constraint is incorrectly formed"。
这不是 Laravel 的 bug，而是数据库层行为：外键约束名绑定的是创建时的表名，不随表重命名而变更。
- 不要依赖
Schema::rename()自动处理外键约束 - 重命名前必须先显式删除原外键约束，再重建指向新表名的约束
- 约束名需手动指定，避免 Laravel 默认生成的旧名残留（如
orders_user_id_foreign→ 改为new_orders_user_id_foreign）
正确重命名带外键的表：三步手动操作
假设要把 orders 表重命名为 customer_orders，且它有 user_id 外键引用 users 表：
- 第一步：在迁移中先用
DB::statement()删除原约束（查出当前约束名：SELECT CONSTRAINT_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_NAME = 'orders' AND CONSTRAINT_SCHEMA = DATABASE() AND REFERENCED_TABLE_NAME IS NOT NULL） - 第二步：调用
Schema::rename('orders', 'customer_orders') - 第三步：用
foreign()显式重建外键，**必须指定新约束名**：$table->foreign('user_id', 'customer_orders_user_id_foreign')->references('id')->on('users')
注意：不能用 foreignId()->constrained() 第三步——它会尝试用旧逻辑生成约束名，仍可能冲突。
foreignId() 在重命名场景下完全不可用
foreignId() 是个“创建即绑定”的快捷方法，内部硬编码了约束名生成逻辑（{表名}_{字段名}_foreign）。一旦表名变更，它就失去上下文，无法适配新表名。
- 重命名后若在新表上再次调用
foreignId('user_id')->constrained()，Laravel 仍会试图建名为orders_user_id_foreign的约束（因模型或迁移上下文未刷新） - 即便表已重命名，
constrained()默认仍去找orders表，而非当前表名 - 唯一安全路径：弃用
foreignId()，全程用unsignedBigInteger()+foreign()手动控制
一列多外键时重命名要额外校验约束名唯一性
如果原表某列（如 order_id）同时关联两个表（users 和 cart_controls），并用了不同约束名（orders_order_id_foreign_users、orders_order_id_foreign_carts），重命名后这些约束名依然无效。
- 每个约束都必须单独
DROP FOREIGN KEY，不能靠一次操作清理 - 重建时新约束名必须反映新表名，且全局唯一（如
customer_orders_order_id_foreign_users） - 遗漏任一约束，后续
migrate:fresh或db:wipe都可能卡在完整性检查上
真正麻烦的不是重命名动作本身，而是约束名和表名之间那种隐式的、不可刷新的绑定关系——它藏在数据库元数据里，Laravel 不感知，也不修复。
