根本原因是外键未成功创建，常见于迁移未执行、字段类型不匹配或表创建顺序错误；需通过php artisan migrate:status确认状态，并用show create table验证约束是否存在。
phpmyadmin 默认不显示 laravel 10 迁移生成的外键约束，根本原因不是 phpmyadmin 有问题，而是外键根本没建成功——多数情况是迁移没跑、类型不匹配或表顺序错，导致约束压根没写进数据库。
phpMyAdmin 里查不到外键，先确认迁移是否真正执行
很多开发者以为 php artisan migrate 跑了就万事大吉，但实际可能：
-
php artisan migrate:status显示对应迁移状态是Pending（没执行） - 刚改了迁移文件（比如加了
foreignId()），但没重新运行migrate:fresh --seed，旧表结构残留 - 迁移文件时间戳比父表迁移还早，导致子表先建、外键引用的表还没存在，MySQL 静默跳过约束
务必先跑 php artisan migrate:status，确保目标表迁移状态为 Ran；若不是，直接 php artisan migrate 或重置环境。
SHOW CREATE TABLE 是唯一可信的验证方式
phpMyAdmin 的“关系视图”只读取 information_schema 中已注册的约束，而它依赖底层真实建表语句。如果外键没建成功，这里必然为空。最可靠办法是直接查数据库：
- MySQL：执行
SHOW CREATE TABLE posts;→ 看输出里有没有CONSTRAINT `posts_user_id_foreign` FOREIGN KEY (`user_id`) REFERENCES `users` (`id`) ON DELETE CASCADE - 如果只有字段定义、没有 CONSTRAINT 行，说明外键根本没生效
- 同时检查字段类型：
user_id必须是bigint unsigned（对应bigIncrements('id')），若父表用的是unsignedInteger('id')，子表用foreignId('user_id')就会失败
Laravel 10 外键写法必须严格匹配字段类型
常见错误写法会让约束“看起来写了，实则无效”：
-
$table->bigInteger('user_id')->unsigned();→ 只建字段，没调->foreign()，约束不存在 -
$table->unsignedBigInteger('user_id');→ 字段对了，但漏掉->foreign('user_id')->references('id')->on('users')或->constrained() -
$table->foreignId('user_id')->constrained();→ 正确，但前提是users.id是bigIncrements()；若父表是id()（Laravel 10 默认等价于bigIncrements），没问题；若手动改成unsignedInteger('id')，这里就会报errno 150
别信 IDE 提示或迁移文件语法高亮，最终以 SHOW CREATE TABLE 输出为准。
SQLite 和 MySQL 的外键启用机制完全不同
如果你用的是 SQLite（比如本地开发）：
- SQLite 默认完全禁用外键，即使迁移写了
foreignId()，也不生效 - 必须在数据库连接时执行
PRAGMA foreign_keys = ON;，Laravel 配置里需加'options' => [PDO::ATTR_EMULATE_PREPARES => false, PDO::MYSQL_ATTR_INIT_COMMAND => 'PRAGMA foreign_keys = ON;'] - phpMyAdmin 不支持 SQLite，所以如果你看到的是 phpMyAdmin 界面，基本可排除 SQLite 场景
真正容易被忽略的点：外键不是“写在迁移里就自动存在”，它是数据库层面的强制约束，任何一步脱节（类型、顺序、执行状态）都会让它消失——而 phpMyAdmin 只忠实地反映数据库现状，不会帮你补漏。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
