Laravel迁移只执行migrations表中标记为“未执行”的文件，需确保命名规范（YYYY_MM_DD_HHIISS_describe_action_table.php）、类名匹配、路径正确；执行前核对.env数据库配置，用migrate:status检查状态，按场景选用对应命令，修改字段需安装doctrine/dbal并显式调用change()。
直接运行 php artisan migrate 就能执行待迁移文件，但多数问题出在没搞清“它到底在迁什么”之前——Laravel 只执行 migrations 表里标记为“未执行”的迁移，不是所有新增文件都会自动跑。
创建迁移前先确认命名与路径规范
迁移文件必须放在 database/migrations/ 目录下，且命名严格遵循 YYYY_MM_DD_HHIISS_describe_action_table.php 格式（如 2024_05_10_123456_create_posts_table.php）。时间戳决定执行顺序，类名必须与文件名完全一致（大小写、复数、下划线均需匹配），否则会报 Class not found。
- 用
php artisan make:migration create_users_table --create=users生成带骨架的建表文件 - 修改已有表用
php artisan make:migration add_phone_to_users_table --table=users - 表名统一小写+下划线，避免大写或短横线，防止 MySQL 拒绝建表
执行迁移前务必核对数据库连接
最常被跳过的是 .env 中的 DB_DATABASE 和 DB_CONNECTION。连错库、连错环境会导致迁移安静地在测试库执行一遍，而你在生产库发现表仍是空的。
- 执行前检查
php artisan tinker中运行DB::connection()->getDatabaseName()确认当前连接库名 - 运行
php artisan migrate:status查看哪些迁移已执行、哪些待执行 - 若提示
Nothing to migrate，查migrations表：SELECT * FROM migrations;看新文件是否已存在记录
按场景选对执行命令，避开静默风险
不同命令作用差异大，误用可能清空数据或静默失败：
-
php artisan migrate：只跑未记录的迁移（安全，日常首选） -
php artisan migrate:rollback：仅撤回最后一次 batch（即一组同时执行的迁移） -
php artisan migrate:reset：逐个执行所有down()并清空migrations表（开发可用，生产禁用） -
php artisan migrate:fresh：先DROP TABLE IF EXISTS所有业务表（不含migrations和failed_jobs），再全量重跑迁移（本地重置用，不重建库、不处理外键异常） -
php artisan migrate --path=2024_05_10_123456_create_posts_table.php：指定单个文件执行（--path是相对路径，别加database/migrations/前缀）
修改字段要额外装依赖并显式调用 change()
Laravel 默认不支持直接修改字段类型或长度，必须安装 doctrine/dbal：
- 运行
composer require doctrine/dbal - 生成迁移：
php artisan make:migration modify_users_email_length --table=users - 在
up()中写：$table->string('email', 191)->nullable()->change();（->change()不可省略） -
down()必须还原原定义，确保可逆
