Laravel迁移与填充失败主因是状态不一致：migrations表记录与实际结构不符、Seeder未显式注册、数据库权限不足、生产环境调试关闭导致错误静默。需逐项校验五要素并同环境验证。
迁移命令在部署后不生效，php artisan migrate 报错“table already exists”
部署后执行迁移失败，多数不是命令写错了，而是 Laravel 的迁移状态和数据库实际结构对不上。Laravel 依赖 migrations 表记录哪些 up() 已执行，如果该表缺失、损坏，或手动建过表但没写入记录，就会反复报“already exists”或“doesn’t exist”。
- 先确认
migrations表是否存在且有数据：SELECT * FROM migrations; - 若表为空，但表结构已存在（比如用 SQL 脚本初始化的），别急着重跑
migrate——先用php artisan migrate:status看哪些迁移显示Ran?为No - 对已存在结构但未记录的迁移，用
php artisan migrate:refresh --step=0不安全；稳妥做法是手动插入记录：INSERT INTO migrations (migration, batch) VALUES ('2014_10_12_000000_create_users_table', 1); - 批量补录时注意
batch值要一致（新批次用最大batch+ 1），否则rollback会出错
php artisan db:seed 执行后没数据，或提示 “Class UsersTableSeeder does not exist”
Laravel 8+ 默认移除了 DatabaseSeeder 中的默认调用，且不再自动发现 Seeder 类——不是命令失效，是注册路径断了。
- 检查
database/seeders/DatabaseSeeder.php，确认run()方法里显式调用了你的 Seeder：$this->call(UsersTableSeeder::class); - Seeder 类名必须与文件名完全一致（包括大小写），且命名空间固定为
DatabaseSeeders；Laravel 不再扫描子目录 - 如果用了
--class参数，类名必须带完整命名空间：php artisan db:seed --class="Database\Seeders\PostsTableSeeder" - 填充前确保迁移已全部完成，否则外键约束会直接中断填充过程
线上环境执行 migrate 或 db:seed 被拒绝：SQLSTATE[HY000] [1045] Access denied
不是 Laravel 配置问题，是部署用户没有对应数据库权限。本地能跑，线上报权限错，90% 是 .env 里的 DB_USERNAME 指向了一个只读账号，或没授权 CREATE/DROP 权限。
- 登录数据库终端，用部署用的账号执行：
SHOW GRANTS FOR 'your_user'@'localhost'; - 至少需要：
GRANT CREATE, ALTER, DROP, INDEX, INSERT, UPDATE, DELETE, SELECT ON your_db.* TO 'your_user'@'%'; - 别用
root账号部署——哪怕临时加权限，也容易因密码策略或 host 限制失败 - 执行完记得
FLUSH PRIVILEGES;，否则权限不生效
CI/CD 自动部署时，migrate 卡住或超时，日志只显示 “Migrating: …”
不是网络或锁表，是 Laravel 在生产环境默认启用 APP_DEBUG=false 后，迁移过程中遇到异常会被静默吞掉，看起来像卡死。
- 上线前先在部署脚本中临时开启调试：
APP_DEBUG=true php artisan migrate --force，看真实错误输出 - 常见真凶：迁移里用了
DB::table()->get()查大量数据，或在up()里调用了外部 API；这些在无交互的 CI 环境下极易超时 - 避免在迁移中做业务逻辑处理；大数据量更新应拆成独立命令或后台任务
- 加
--no-interaction和--force是必须的，否则遇到 “There are uncommitted migrations” 会阻塞等待输入
迁移和填充最麻烦的从来不是语法，而是状态不一致——数据库结构、migrations 表、代码里的迁移文件、.env 配置、数据库账号权限，这五者只要一个脱节，就只能靠人工比对。尤其上线前别信“本地跑过就行”，得在同环境、同账号、同配置下走一遍全流程。
