Laravel迁移干嘛用？迁移文件如何创建执行？-Laravel-PHP中文网

Laravel迁移通过PHP代码实现数据库版本控制，解决团队协作、环境一致性及回滚难题。开发者使用Artisan命令创建迁移文件，定义up()和down()方法管理数据库变更，执行migrate命令同步结构，支持rollback、refresh等操作确保可追溯与安全回滚，避免直接修改数据库导致的失控风险。

laravel迁移干嘛用？迁移文件如何创建执行？

Laravel迁移，简单来说，就是用代码管理数据库结构变化的工具。它把原本需要你手动编写SQL语句来创建、修改或删除数据库表、字段的繁琐过程，转化成了更优雅、可版本控制的PHP代码。这对于团队协作和环境部署来说，简直是救星。

解决方案

Laravel迁移的核心作用是实现数据库的版本控制。它允许你通过PHP代码来定义和修改数据库结构，而不是直接去操作SQL文件或数据库管理工具。这样做的好处是多方面的，也是我个人在实际项目中深有体会的地方。

首先，它解决了团队协作中的大痛点。想象一下，一个项目有多个开发者，每个人都在修改数据库结构，比如有人加了新表，有人给旧表加了字段。如果没有迁移，你们需要不断地同步SQL文件，或者口头告知，这中间极易出错，而且合并冲突简直是噩梦。但有了迁移，这些变更都以代码的形式存在，可以和业务代码一起提交到版本控制系统（比如Git），大家拉取最新代码后，运行一个命令就能同步数据库结构，冲突解决也变得清晰可控。

其次，它保证了不同环境之间（开发、测试、生产）数据库结构的一致性。我遇到过不少情况，开发环境的数据库结构是A版本，测试环境是B版本，生产环境又是C版本，导致各种莫名其妙的bug。迁移强制了这种一致性，每次部署都确保数据库结构是预期的最新版本。

最后，它提供了可追溯性和回滚能力。每次数据库结构的变化都被记录在一个独立的迁移文件中，你可以清楚地看到历史上的每一次变更。如果某个变更导致了问题，你也可以轻松地回滚到之前的稳定状态，这在紧急情况下尤其重要。我记得有一次，上线后发现某个新字段的类型定义错了，导致数据写入失败，幸好有迁移，快速回滚然后修复再部署，避免了长时间的服务中断。

如何创建和编写一个Laravel迁移文件？

创建Laravel迁移文件，最常用的方式就是通过Artisan命令行工具。这就像是Laravel给你提供了一个魔法棒，轻轻一点，文件就为你准备好了。

如果你想创建一个全新的表，比如

users

登录后复制

表，你可以运行：

php artisan make:migration create_users_table --create=users

登录后复制

这里的

create_users_table

登录后复制

是迁移文件的命名，Laravel会根据这个名字生成一个带时间戳的文件名。

--create=users

登录后复制

参数则告诉Artisan，这个迁移是用来创建

users

登录后复制

表的，它会自动在生成的迁移文件中为你添加一些基础的表结构代码。

如果你只是想给已有的表添加或修改字段，比如给

users

登录后复制

表添加一个

email

登录后复制

字段，你可以这样：

php artisan make:migration add_email_to_users_table --table=users

登录后复制

--table=users

登录后复制

参数会生成一个空的

up()

登录后复制

和

down()

登录后复制

方法，你需要手动在里面编写修改表结构的代码。

迁移文件生成后，你会发现它位于

database/migrations

登录后复制

目录下。每个迁移文件都包含两个核心方法：

up()

登录后复制

和

down()

登录后复制

。

Fireflies.ai

自动化会议记录和笔记工具，可以帮助你的团队记录、转录、搜索和分析语音对话。

145

查看详情

```
up()
```
登录后复制
方法：当执行迁移时，这个方法会被调用。你在这里定义数据库结构的变化，比如创建表、添加字段、修改字段类型等。
```
down()
```
登录后复制
方法：当回滚迁移时，这个方法会被调用。它应该包含
```
up()
```
登录后复制
方法操作的逆向逻辑，比如删除表、删除字段等，确保回滚操作能恢复到之前的状态。

举个简单的例子，一个创建

products

登录后复制

表的迁移文件可能看起来像这样：

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

return new class extends Migration
{
    /**
     * Run the migrations.
     */
    public function up(): void
    {
        Schema::create('products', function (Blueprint $table) {
            $table->id(); // 自增主键
            $table->string('name')->unique(); // 产品名称，唯一
            $table->text('description')->nullable(); // 产品描述，可为空
            $table->decimal('price', 8, 2); // 价格，总共8位，小数点后2位
            $table->timestamps(); // created_at 和 updated_at 字段
        });
    }

    /**
     * Reverse the migrations.
     */
    public function down(): void
    {
        Schema::dropIfExists('products'); // 如果表存在，则删除
    }
};

登录后复制

这里的

Schema::create

登录后复制

和

Schema::dropIfExists

登录后复制

是Laravel提供的Schema Builder的一部分，它允许你用更具表现力的PHP代码来定义数据库结构，而不用直接写SQL。

Laravel迁移文件创建后该如何执行？以及如何回滚？

创建好迁移文件只是第一步，要让这些数据库结构的变化真正生效，你还需要执行它们。Artisan工具再次派上用场。

执行迁移： 最基本的执行命令是：

php artisan migrate

登录后复制

当你运行这个命令时，Laravel会检查

database/migrations

登录后复制

目录下所有尚未执行的迁移文件，并按照时间戳的顺序依次运行它们的

up()

登录后复制

方法。Laravel会在你的数据库中维护一个

migrations

登录后复制

表，用来记录哪些迁移已经运行过，所以它不会重复执行。

回滚迁移： 有时候，你可能需要撤销最近的数据库结构变更，这时候就需要回滚操作。

回滚最近一批迁移：
```
php artisan migrate:rollback
```
登录后复制
这个命令会回滚最近一次执行的（一批）迁移。也就是说，如果你一次性执行了5个新的迁移，这个命令会把这5个都回滚掉，调用它们的
```
down()
```
登录后复制
方法。
回滚所有迁移：
```
php artisan migrate:reset
```
登录后复制
这个命令会回滚所有已经运行过的迁移，相当于把数据库结构恢复到初始状态（即所有迁移都未执行前的状态）。
刷新数据库（回滚并重新执行所有迁移）：
```
php artisan migrate:refresh
```
登录后复制
这个命令实际上是
```
migrate:reset
```
登录后复制
和
```
migrate
```
登录后复制
的组合。它会先回滚所有迁移，然后重新运行所有迁移。这在开发过程中非常有用，当你频繁修改数据库结构并希望快速重置数据库到最新状态时，它能帮你省不少事。不过，请务必注意，
```
migrate:refresh
```
登录后复制
会丢失所有数据，所以千万不要在生产环境轻易使用！
彻底刷新数据库（删除所有表并重新执行所有迁移）：
```
php artisan migrate:fresh
```
登录后复制
这是更彻底的重置。它会删除数据库中所有的表，然后重新运行所有迁移。这个命令比
```
migrate:refresh
```
登录后复制
更“暴力”，因为它不依赖于
```
down()
```
登录后复制
方法来回滚，而是直接清空数据库。在开发初期，当你数据库结构变动非常频繁，或者想确保数据库完全干净时，这个命令很好用。但同样，它会丢失所有数据，生产环境严禁使用。

我个人在开发阶段，

php artisan migrate:refresh --seed

登录后复制

（结合填充器）几乎是我的日常操作。每次数据库结构有变动，或者想测试某个功能，一键重置数据库并填充测试数据，效率直接拉满。但上线前，我都会再三确认，生怕手滑在生产环境敲错命令。

为什么不直接在数据库里修改，非要用迁移？

这其实是一个非常经典的问题，尤其是对于刚接触Laravel或者习惯了直接操作数据库的开发者来说。说实话，刚开始接触Laravel迁移的时候，我也曾不以为然，觉得直接写SQL不是更快吗？或者直接在Navicat、DataGrip里点点鼠标不香吗？但很快我就被打脸了，尤其是在团队协作和项目迭代中，迁移的价值简直是无可替代的。

版本控制的缺失： 直接在数据库里修改，最大的问题就是缺乏版本控制。你的数据库结构就像一个黑箱，你修改了什么，什么时候修改的，为什么修改的，都很难追溯。这就像你在Git项目里不提交就改代码，然后期望别人知道你改了什么。一旦出了问题，想要回溯到某个版本，几乎是不可能完成的任务。迁移则把数据库结构变更纳入了代码版本控制，每一次变更都清晰可见。

环境差异的噩梦： 我经历过最痛苦的场景之一就是开发、测试、生产环境数据库结构不一致。开发人员可能在本地加了个字段，但忘记告诉测试人员，导致测试环境的某个功能报错。或者生产环境的数据库结构因为某些原因被手动修改了，和代码库里的预期不符，导致上线后出现各种奇葩bug。迁移强制了这种一致性。只要大家运行相同的迁移，所有环境的数据库结构就应该是一致的。

团队协作的障碍： 在一个团队中，如果大家都是直接修改数据库，那么同步数据库结构会成为一个巨大的负担。新加入的成员需要一份最新的SQL文件来初始化数据库，而每次有人修改了结构，都需要通知所有人更新。这不仅效率低下，而且极易出错。迁移则简化了这个流程，新成员只需要拉取代码，运行