我刚接手一个老项目时，打开代码库第一眼就懵了。数据库表结构全靠手写 SQL，开发、测试、生产三个环境，每次改字段都得群发邮件通知同事：“我改了 users 表，你们自己手动跑一下这个 SQL。”结果总有人忘记同步，一上线就报错。那段时间我明白了，没有数据库迁移工具的项目，就像没有刹车的车——能跑，但随时可能翻车。后来换到 Laravel，发现它自带的迁移功能简直是手残党的救星。只需要写好迁移文件，执行一句 ，所有环境的表结构就自动对齐。这个过程不需要记什么 SQL 语法，Laravel 的 Schema 构建器会帮你生成兼容多种数据库的代码。如果你之前还在用 phpMyAdmin 手动建表，看完这篇你会想把键盘摔了。
Laravel 数据库迁移的核心价值在于把数据库版本控制变成代码管理。想象一下，你和团队在开发一个电商系统，产品经理突然说要给订单表加一个 “优惠券 ID” 字段。以前的做法是直接连上生产库，小心翼翼敲个 ALTER TABLE，旁边还得有人盯着防止手滑。但有了迁移，只需要在项目里新建一个迁移文件，写下然后提交到 Git。同事拉取代码后执行 ，表结构就自动更新。更爽的是，如果改错了， 能回滚到上一个版本。这就像给数据库装上了时光机，想回到过去就回到过去。
不过，刚接触 Laravel 迁移的人容易犯一个错误：在迁移文件里写模型关联或业务逻辑。我记得有一次，一个新手同事在迁移里写了个数据填充的循环，结果每次执行迁移都往库里插几万条测试数据，大家以为系统被攻击了。迁移文件的核心职责只有两点：描述表结构的变化，以及定义如何撤销这个变化。别在里面塞计算、发邮件、调接口之类的代码。迁移本身是一次性操作，如果依赖了某个模型，而模型后来被删了，迁移就会报错，导致无法回滚。保持迁移文件的纯粹，只写 Schema 操作，其他事情留给 Seeder 或队列任务去做。
实际开发中，我见过最头疼的情况是直接修改历史迁移文件。比如上个月创建了 users 表，这个月发现少了个字段，直接打开那个迁移文件，在 方法里加了一行 。本地跑 没问题，但同事拉取代码后执行时报错，提示字段已存在。这是因为迁移文件一旦执行，Laravel 会在 表里记录批次号。修改历史文件后，系统认为它已经跑过，不会再执行。正确的做法是新建一个迁移文件来修改表结构。迁移文件是用来记录变更历史的，而不是编辑历史的。就像写日记，你可以每天写新的一页，但不能撕掉旧的那页重写。
说到迁移的最佳实践，命名规范是容易忽略的细节。Laravel 默认生成的迁移文件名类似 ，时间戳保证了执行顺序。但如果自己手动创建迁移，千万别用 这种名字，时间戳冲突会导致顺序混乱。我习惯使用描述性前缀，如 或 ，Laravel 的生成器 会自动加时间戳。另外，每个迁移文件只做一件事：要么建表，要么加字段，要么改索引。把多个操作揉在一个文件里，回滚时会出现问题。比如同时加字段和改索引，回滚只撤销字段，索引仍在，下次再跑就会冲突。
还有个小技巧：要分清 和 的区别。前者会删除所有表再重新跑迁移，适合本地开发环境清空数据；后者先回滚所有迁移再重新执行，适合改了多个迁移文件后想完整测试。但千万别在生产环境使用这两个命令，除非想被老板炒鱿鱼。生产环境只用正常的 ，它只会执行未跑过的迁移。我见过有人误操作在线上跑了 ，几十万条订单瞬间消失，恢复备份花了整整两天。所以，我习惯在迁移文件的 方法里加防护逻辑：如果检测到是生产环境就抛异常，阻止手滑。
说到底，Laravel 数据库迁移不是可有可无的功能，而是现代 Web 开发的标配。它把数据库结构的管理从“人工运维”提升到“代码管理”。你在 Git 上能看到每次表结构变更的代码、提交人和修改时间，团队协作再也不用靠吼来同步数据库。测试环境可以随时重建，CI/CD 流水线里跑个 就能保证数据结构一致。如果你还在用 SQL 文件手动导入来同步数据库，建议试试 Laravel 迁移，花半小时学会，能省下半年的加班时间。毕竟，程序员最该偷懒的地方，就是那些重复性高、容易出错的操作。数据库迁移，就是把这种“脏活”变成优雅的代码。
