外键迁移报“Cannot add or update a child row”根本原因是现有数据不满足约束，需先查并清理孤儿记录（如SELECT * FROM orders WHERE user_id NOT IN (SELECT id FROM users)），再执行迁移。
外键迁移时提示 “Cannot add or update a child row”
这是最常见的报错，根本原因不是语法写错了，而是现有数据不满足外键约束条件。比如你给 orders.user_id 加外键指向 users.id，但当前已有某些 orders.user_id 的值在 users 表里根本不存在。
- 加外键前先检查脏数据：
SELECT * FROM orders WHERE user_id NOT IN (SELECT id FROM users); - 要么清理掉这些孤儿记录，要么把它们设为
NULL（前提是字段允许 NULL） - MySQL 5.7+ 默认开启
STRICT_TRANS_TABLES，会让这类问题直接报错；开发环境可临时关掉（不推荐上线用）：SET SESSION sql_mode = ''; - 迁移里用
foreignId()+constrained()是最稳妥的写法，它自动匹配表名和字段名，减少手误
Laravel 9+ 中 foreignId() 和 unsignedBigInteger() 选哪个
必须用 foreignId()。它不只是类型别名，还自带语义和链式能力，而 unsignedBigInteger() 只是原始类型声明，后续加约束容易漏步骤。
-
foreignId('user_id')等价于unsignedBigInteger('user_id')，但前者能直接链式调用constrained() -
constrained()默认找users表、id字段；如果关联表名不同（比如admins），得显式传参：constrained('admins') - 如果字段名不是标准格式（如叫
created_by_id），constrained()会猜错目标表，这时要手动指定：constrained('users')->onUpdate('cascade') - 别在已有数据的表上直接加外键约束——哪怕类型完全匹配，也得先确保值全部合法
迁移回滚时报 “Cannot drop index 'xxx': needed in a foreign key constraint”
这是 MySQL 的限制：不能直接删被外键引用的索引。Laravel 默认给外键字段建索引，但回滚时如果只删字段不先删外键，就会卡在这里。
- 回滚迁移里必须先删外键，再删字段。顺序不能反：
$table->dropForeign(['user_id']); $table->dropColumn('user_id'); - 外键名默认是
table_name_column_name_foreign，比如orders_user_id_foreign；用php artisan schema:dump可查当前所有外键名 - 更安全的做法是在创建时就指定外键名：
->foreignId('user_id')->constrained()->cascadeOnDelete()->name('fk_orders_user_id')，这样回滚时明确可控 - 如果已经卡住，手动进数据库执行：
ALTER TABLE orders DROP FOREIGN KEY fk_orders_user_id;
SQLite 开发时外键不生效，但生产 MySQL 没问题
SQLite 默认关闭外键支持，Laravel 迁移不会帮你打开它，所以本地测试可能“假装成功”，上线却出问题。
- SQLite 必须在连接后执行
PRAGMA foreign_keys = ON;才生效；Laravel 需在config/database.php的 SQLite 配置里加'options' => [PDO::ATTR_EMULATE_PREPARES => true, PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC],并在服务提供者或启动脚本中手动执行 PRAGMA - 更现实的做法是：开发阶段不用 SQLite 做外键验证，改用 MySQL 容器（如 Laravel Sail）保持一致性
- 不要依赖 SQLite 的外键行为做逻辑判断，它的约束粒度和错误提示跟 MySQL 差很多
外键不是加了就完事，真正麻烦的是数据一致性校验时机——它只拦 INSERT/UPDATE，不扫历史数据；线上加约束前务必跑通数据清洗，否则迁移一半失败，表就卡在中间状态。
