Laravel迁移执行失败的根本原因是未理解其触发逻辑与状态管理机制；需确保迁移文件命名规范、目录正确、类名匹配，且数据库结构、迁移文件与migrations表三者状态一致。
直接运行 php artisan migrate 就能执行迁移，但多数人卡在“没反应”“报错”或“改了文件却没生效”上——根本原因不是命令不会输，而是没搞清 Laravel 迁移的触发逻辑和状态管理机制。
迁移文件为什么没被识别？检查 migrations 目录和命名规范
Laravel 只扫描 database/migrations/ 下、且文件名严格匹配 YYYY_MM_DD_HHMMSS_create_posts_table.php 这类格式的 PHP 文件。时间戳必须是数字，不能含中文、空格或下划线以外的符号；类名必须与文件名一致（如 CreatePostsTable），且继承 Migration。
- 常见错误现象：
Nothing to migrate，但明明加了新文件 —— 很可能是文件名漏了时间戳、用了短横线（-）而非下划线（_），或放错了目录（比如丢进app/） - 使用场景：团队协作时，有人手动重命名迁移文件导致格式失效；或从旧项目复制文件时保留了原时间戳，造成时间冲突
- 建议用
php artisan make:migration create_users_table生成，避免手写格式出错
php artisan migrate 执行失败的三个高频原因
迁移命令本身不报错，不代表执行成功；它依赖数据库连接、表结构兼容性和已记录的迁移历史。失败往往发生在 SQL 层或状态校验层。
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
-
SQLSTATE[HY000]: General error: 1005 Can't create table：外键字段类型不一致（比如关联id是BIGINT UNSIGNED，而你的user_id是INT），或存储引擎不支持（MyISAM 不支持外键） -
Base table or view not found：在down()方法里删表，但该表已被手动删除，或up()中依赖的表还没建好 - 迁移中途中断后再次运行报错：Laravel 记录已执行的迁移在
migrations表里，如果某次失败导致部分 SQL 执行了但记录没写入，下次会跳过该文件，造成数据/结构不一致
什么时候该用 migrate:fresh 而不是 migrate:reset？
migrate:reset 只调用每个迁移的 down() 方法回滚，依赖你写的逻辑是否完整可靠；migrate:fresh 则直接删库重建（默认删所有表），绕过所有 down()，适合本地开发环境快速重置。
- 性能影响：
migrate:fresh在大表上极慢，且无法保留测试数据；migrate:reset如果down()写了dropIfExists()而不是drop()，可能残留空表 - 兼容性注意：MySQL 8.0+ 默认开启
ONLY_FULL_GROUP_BY，某些down()里的 SQL 可能因此报错，migrate:fresh反而更稳 - 安全边界：生产环境严禁用这两个命令，
migrate:fresh尤其危险 —— 它不检查是否在 production 环境，只看APP_ENV配置，而这个配置可能被误设
修改已执行的迁移文件后怎么更新数据库？
不能直接改完再跑 migrate —— Laravel 会跳过已记录的迁移文件。正确做法是：先用 migrate:rollback 回滚最后一批（默认 1 次），再改文件，再 migrate；或者，更稳妥的是新建一个迁移来修正（比如加字段、改类型）。
- 容易踩的坑：有人改完文件直接
db:wipe或删migrations表，结果线上环境同步时缺失历史记录，CI 流水线炸掉 - 为什么这样做：Laravel 的迁移本质是“有序变更日志”，不是“当前结构快照”。强行篡改已提交的迁移，等于伪造历史，在多人协作中极易引发结构漂移
- 示例：想给
users表加phone字段，别改create_users_table.php，而是运行php artisan make:migration add_phone_to_users_table，然后在新文件里写$table->string('phone')->nullable()
迁移不是“写完就跑”的一次性操作，它的真正复杂点在于状态一致性 —— 数据库实际结构、迁移文件内容、migrations 表记录，这三者必须时刻对齐。任何一方脱节，后面都是连环报错。
