为何无法使用Laravel生成的迁移文件名执行迁移？

首先得明确Laravel迁移的核心逻辑：它会把所有成功执行的迁移记录在migrations数据表中，每次运行php artisan migrate时，只会执行未被记录的迁移文件，且是按文件名的时间戳从小到大排序执行的。结合你遇到的情况，咱们一步步排查解决：

第一步：检查migrations表的记录 #

先登录你的数据库，执行这条SQL查询：

SELECT * FROM migrations;

重点查看结果里有没有create_admins_table和create_password_resets_table这两条记录。

情况A：记录存在，但对应的数据表没创建 #

这说明迁移被标记为已执行，但实际执行时出了异常（比如中途中断、数据库权限不足、语法错误等）。解决步骤：

1. 删除migrations表中对应的这两条记录
2. 确认你的迁移文件up()方法没有语法错误（比如字段定义写错、拼写错误）
3. 重新运行php artisan migrate

情况B：记录不存在，但2018年的admin迁移无法执行，改成2014年就成功 #

这种情况大概率是以下原因导致的，逐个排查：

• 系统时区/时间异常：检查服务器或本地开发环境的时间、时区是否正确。Laravel会根据文件时间戳排序迁移，如果系统时间和文件时间的时区不匹配，可能会打乱执行顺序。你可以通过php artisan tinker执行date('Y-m-d H:i:s')，查看Laravel使用的时间是否和预期一致。
• 文件名格式问题：确认迁移文件名严格遵循YYYY_MM_DD_HHMMSS_create_xxx_table.php的格式，有没有年份少写一位、分隔符用错（比如用.代替_）这类细节错误。
• 强制执行单个迁移：如果以上都没问题，试试单独执行这个迁移文件，看是否会报错：

  php artisan migrate --path=/database/migrations/2018_04_19_095256_create_admins_table.php
  

  控制台的报错信息会帮你定位具体问题。

针对create_password_resets_table的额外处理 #

这个表一般是Laravel自带的迁移，如果你是手动创建的，先确认up()方法内容正确：

public function up()
{
    Schema::create('password_resets', function (Blueprint $table) {
        $table->string('email')->index();
        $table->string('token');
        $table->timestamp('created_at')->nullable();
    });
}

内容没问题的话，同样按照上面的步骤检查migrations表记录，删除已存在的记录后重新执行迁移即可。

后续预防建议 #

• 尽量不要手动修改迁移文件的时间戳，除非你明确知道这么做的影响
• 每次执行迁移后，顺手检查下数据库是否生成了对应表，以及migrations表的记录是否正常
• 迁移失败时一定要看控制台的错误提示，不要忽略任何异常信息

内容的提问来源于stack exchange，提问作者Low Profile