Laravel数据库迁移是版本化协作机制，必须用php artisan make:migration生成带时间戳文件并执行migrate命令；新建表需用Schema::create()，修改字段须新建迁移且安装doctrine/dbal；外键依赖时间戳顺序，生产环境迁移需--force、避峰、备份。
在 Laravel 中，数据库迁移不是“同步结构”的快捷键，而是通过版本化脚本控制表结构演进的协作机制。所有操作必须走 php artisan make:migration 生成文件 + php artisan migrate 执行流程，跳过校验或手动改库会破坏 migrations 表，导致回滚失败、部署异常甚至团队协作事故。
创建新数据表的规范流程
新建表不能写原生 SQL，也不能手建文件名——必须用 Artisan 命令生成带时间戳的迁移文件，确保执行顺序可靠：
- 运行
php artisan make:migration create_users_table --create=users，自动生成类似2026_06_04_100000_create_users_table.php的文件 - 打开文件，在
up()中使用Schema::create()定义结构，例如：$table->id();（等价于bigIncrements('id')）$table->string('name')->nullable();（显式声明 NULL 才允许为空）$table->timestamps();（自动添加created_at和updated_at，类型为datetime） - 不写
down()方法或只写Schema::dropIfExists('users')即可，Laravel 默认支持安全删除
安全修改已有字段的硬性要求
加字段、改长度、调类型、设约束……所有变更都必须新建迁移，绝不可编辑已提交的老文件。关键前提是安装 doctrine/dbal：
- 先执行
composer require doctrine/dbal，否则change()会报错或静默失效 - 生成迁移：例如
php artisan make:migration add_email_to_users_table --table=users - 在
up()中用Schema::table()+change()，例如：$table->string('email', 255)->unique()->change();
注意：必须链式调用->change()，否则只是定义，不触发 ALTER 操作 -
down()要写对应回滚逻辑，比如把长度改回去、取消唯一约束等
外键与执行顺序的避坑要点
外键失败（如 “Failed to open the referenced table”）几乎全是顺序问题，和时间戳强绑定：
- Laravel 严格按迁移文件名前缀（年_月_日_时分秒）升序执行，不是按创建先后或文件名直觉排序
- 若
posts表要引用users，则create_users_table的时间戳必须早于create_posts_table - 禁止手动改时间戳“抢序”——本地能跑，上线就崩，且无法追溯
- 出错后别删
migrations表记录，先用php artisan migrate:rollback --step=1回退一步，修复依赖再重试
生产环境执行迁移的特别提醒
上线不是开发环境，迁移需兼顾数据安全与服务可用：
- 加字段类轻量变更一般无锁，但改类型（如
string → text）、增索引、加外键可能触发全表重建，MySQL 下易锁表 - 务必在测试库完整跑通后再上生产；建议配合备份，尤其涉及
change()的操作 - 生产执行需加
--force参数：php artisan migrate --force，否则交互式确认会卡住 - 避免在高流量时段执行，大表变更考虑分步（如先加字段，再用命令行批量更新值）
