php artisan migrate 仅执行 migrations 表中未记录的迁移文件；若提示“nothing to migrate”，需检查文件路径、命名格式（yyyy_mm_dd_hhmmss_*）、migrations 表记录及数据库连接配置。
php artisan migrate 能跑起来，不代表它真在迁你要的那张表——多数问题出在 Laravel 不是“看到文件就执行”，而是查 migrations 表后才决定动不动手。
为什么 php artisan migrate 提示 “Nothing to migrate”
这不是命令错了，是 Laravel 严格按 migrations 表里的记录来判断是否该执行。哪怕你刚加了 2026_04_19_100000_create_logs_table.php，只要它没出现在 migrations 表里，就不会跑；反过来，如果表已存在、且对应记录已在表中，它就彻底跳过。
- 检查迁移文件是否真的在
database/migrations/目录下，且命名符合YYYY_MM_DD_HHMMSS_*格式（只能用数字和下划线，不能有中文、短横线或空格） - 手动查库：
SELECT * FROM migrations WHERE migration = '2026_04_19_100000_create_logs_table';，看有没有这条记录 - 如果误删过表但忘了清
migrations表里的对应行，Laravel 会以为“这活儿干过了”，此时要么用php artisan migrate:reset回滚再重试，要么（仅限开发环境）直接DELETE FROM migrations WHERE migration = '...'; - 别忽略
.env里的DB_DATABASE和DB_CONNECTION——连错库，迁移可能安静地在测试库执行一遍，而你在生产库发现表还是空的
php artisan migrate:fresh 到底在干什么
它不是“重新跑一遍迁移”，而是先 DROP TABLE IF EXISTS 所有业务表（跳过 migrations 和 failed_jobs），再从头执行全部 up() 方法。它绕过了所有 down() 逻辑，也不管你有没有外键约束、视图或触发器。
- 生产环境绝对禁用；本地开发慎用——它不区分“有没有重要数据”，删完就删完
- 如果你在某个迁移里写了
Schema::dropIfExists('posts')，migrate:fresh还是会执行它，可能导致重复删表报错 - 大表上执行极慢，且无法保留任何测试数据；想留部分数据？得改用
php artisan migrate:rollback --step=1+ 手动调整迁移内容 - MySQL 8.0+ 开启
ONLY_FULL_GROUP_BY时，某些down()里的 SQL 可能报错，migrate:fresh反而更稳（因为它根本不用down()）
用 --path 或 --realpath 指定单个迁移文件时怎么不出错
--path 是相对路径，从 database/migrations/ 开始算；--realpath 必须传绝对路径，且 Laravel 完全不校验路径是否存在——写错就静默失败。
- 正确指定单个文件：
php artisan migrate --path=2026_04_19_100000_create_logs_table.php - 错误示范：
php artisan migrate --path=database/migrations/2026_04_19_100000_create_logs_table.php（Laravel 会拼成database/migrations/database/migrations/...，路径双重复） - 用
--realpath时必须给绝对路径：php artisan migrate --realpath=/var/www/myapp/custom_migrations/2026_04_19.php - 注意：即使指定了单个文件，它的
up()里若依赖其他未执行的迁移（比如先建users才能建user_profiles），依然会报错
改了已执行的迁移文件后怎么生效
不能直接改完再跑 php artisan migrate——Laravel 会跳过所有已在 migrations 表里标记为“已完成”的文件，无论你改得多认真。
- 开发阶段最安全的做法：用
php artisan migrate:rollback --step=1回滚最后一步，删掉对应migrations表记录，再改文件、重新migrate - 如果只是加字段，建议另起一个迁移：
php artisan make:migration add_status_to_posts_table --table=posts，而不是硬改旧文件 - 线上环境严禁修改已提交的迁移文件；若结构已错，应补新迁移 + 写好兼容逻辑，而不是碰老文件
最容易被忽略的是：迁移不是“写完就跑”，而是状态驱动的——migrations 表才是权威，文件只是源码。连错库、时间戳格式错、手动删表却忘了清理记录，都会让整个流程静默失效。
