外键加不上主因是字段类型不匹配、数据脏或迁移顺序错误；应优先用foreignId()而非unsignedBigInteger()，因其自动适配主键类型、支持constrained()链式调用并默认建索引，且能精准规避errno 150错误。
外键加不上，八成不是语法写错了，而是字段类型不匹配、数据脏、或者迁移顺序/回滚逻辑没理清——这些问题在 Laravel 迁移里高频出现，且报错信息（比如 errno 150 或 Cannot add or update a child row）看似模糊，其实指向非常明确。
foreignId() 和 unsignedBigInteger() 到底该用哪个
必须用 foreignId()。它不只是 unsignedBigInteger() 的别名，而是带语义的类型声明：自动适配主键类型、支持链式 constrained()、且后续加 onDelete() 等约束更自然。
-
unsignedBigInteger('user_id')只是建一个无符号整型字段，不附带任何外键语义，你得手动补->foreign('user_id')→…，漏一步就白忙 -
foreignId('user_id')默认等价于unsignedBigInteger('user_id')，但立刻能接->constrained()，一行搞定字段 + 约束 + 索引 - Laravel 9+ 中，
foreignId()还会自动为该字段加索引（MySQL 查询优化必需），而unsignedBigInteger()不会
加外键时报 errno 150 怎么快速定位
这是 MySQL 层面的硬性校验失败，根本原因是外键列和被引用主键列的定义不一致——类型、符号、长度、是否允许 NULL，只要有一项对不上就报错。
- 检查主键表：如果
users表用的是$table->id()（即bigincrements），那外键字段必须是foreignId('user_id')或显式unsignedBigInteger('user_id')->unsigned() - 禁止混用：
BigInteger('user_id')->unsigned()是错的，因为BigInteger()默认有符号，即使加了->unsigned()也可能因底层实现差异触发 150 - 检查是否已存在数据：已有记录的
user_id值必须全部存在于users.id中，否则加约束时直接失败。先跑这条查孤儿：SELECT * FROM orders WHERE user_id NOT IN (SELECT id FROM users);
constrained() 方法为什么有时不生效
constrained() 是个“聪明但有默认假设”的语法糖，默认找目标表的 id 字段。一旦你的主键不是 id，它就失效。
- 比如
users表主键是user_id：$table->id('user_id')，那么constrained('users')会去查users.id→ 字段不存在 → 报errno 150 - 正确写法是显式传入主键字段名：
->constrained('users', 'user_id')，这等价于->references('user_id')->on('users') - 如果外键字段名不标准（如叫
created_by_id），constrained()会猜错表名（比如猜成created_bies），这时也得手动指定：->constrained('users')
已有数据的表怎么安全加外键
不能直接在 up() 里加字段再加约束——哪怕类型完全匹配，只要数据里有非法值，迁移就会中断。
- 分两步走：先加字段（允许 NULL），运行一次迁移；再单独建一个迁移，只做
foreign()+constrained()，并在执行前人工清理或修正脏数据 - 如果字段不允许 NULL，又必须加外键，得先确保所有现有记录都合法：
UPDATE orders SET user_id = NULL WHERE user_id NOT IN (SELECT id FROM users);（前提是字段允许 NULL） - 回滚时尤其注意顺序：必须先删外键，再删字段。否则 MySQL 报
Cannot drop index 'xxx': needed in a foreign key constraint。回滚代码要写成：$table->dropForeign(['user_id']); $table->dropColumn('user_id');
最易被忽略的一点：外键约束名默认由 Laravel 自动生成（如 orders_user_id_foreign），但如果你要在同一字段上建多个外键（比如 order_id 同时关联 users 和 cart_controls），就必须手动指定唯一约束名，否则 MySQL 拒绝重复命名——这个细节在多态或复杂业务建模时才暴露，但一出问题就卡死。
