php artisan migrate 只执行 migrations 表中未标记的迁移文件；若提示“Nothing to migrate”，需检查文件路径、命名格式、migrations 表记录及数据库连接配置。
直接运行 php artisan migrate 就能执行待迁移文件，但多数报错和数据丢失都发生在没搞清“它到底在迁什么”之前。
为什么 php artisan migrate 没反应或提示“Nothing to migrate”
不是命令错了，是 Laravel 默认只运行 status 表里标记为“未执行”的迁移——哪怕你刚新增了 create_posts_table.php，只要它没被记录进 migrations 表，就不会跑；反过来，如果表已存在、且对应记录已在 migrations 表里，它就真的一动不动。
- 先确认迁移文件是否在
database/migrations/下，且命名符合2024_05_10_123456_create_posts_table.php格式（时间戳+下划线+描述） - 检查
migrations表：运行SELECT * FROM migrations;，看新文件的batch和migration字段是否已存在 - 误删过表但没清理
migrations表？用php artisan migrate:reset回滚再重试，或手动删掉对应记录（仅开发环境）
php artisan migrate:fresh 会清空所有表，但它不等于重装数据库
这个命令本质是先 DROP TABLE IF EXISTS 所有业务表（不含 migrations 和 failed_jobs），再重新跑全部迁移。但它不会重建数据库本身，也不会处理外键约束异常、视图、存储过程等非迁移管理的内容。
- 生产环境绝对禁用，本地开发慎用：它不区分“是否已有数据”，删完就删完
- 如果迁移中用了
Schema::dropIfExists('xxx')，migrate:fresh仍会执行该语句——可能重复删表报错 - 想保留部分数据？改用
php artisan migrate:rollback --step=1+ 手动调整迁移文件，再migrate
带参数运行迁移时，--path 和 --realpath 容易混淆
--path 是相对路径，从 database/migrations/ 开始算；--realpath 则必须传绝对路径，且 Laravel 不校验路径是否存在——错写就静默失败。
- 正确指定单个文件：
php artisan migrate --path=2024_05_10_123456_create_posts_table.php - 错误示范：
php artisan migrate --path=database/migrations/2024_05_10_123456_create_posts_table.php（会拼成双重复路径） -
--realpath仅用于从非标准目录加载，比如php artisan migrate --realpath=/var/www/myapp/custom_migrations/2024_05_10.php - 所有
--path指定的文件，仍需确保其up()方法里没有依赖未执行的其他迁移
最常被跳过的其实是 .env 里的 DB_DATABASE 和 DB_CONNECTION——连错库、连错环境，迁移会安静地在测试库执行一遍，然后你在生产库发现表还是空的。
