刚接触 Laravel 那会儿，我对数据库迁移这玩意儿挺不屑的。不是一堆 PHP 文件嘛，手动建表不是更直接？直到有次项目上线，测试环境和生产环境的表结构差了三个字段，我对着 SQL 文件一个个手工比对，改完一个忘了另一个，数据全乱了。那天晚上加班到凌晨三点，我一边骂娘一边想：要是早点用迁移，至于这么狼狈吗？从那以后，我彻底服了，数据库迁移这东西看着麻烦，用起来却真香。
说穿了，迁移就是把数据库结构的变化记录下来，像版本控制一样。你写一个迁移文件，里面定义好要创建的表、要加的字段、要建的索引，然后跑一条命令，这些变动就自动应用到数据库里。团队协作时，每个人都可以在自己的环境里跑一遍迁移，表结构就完全同步了。不用再相互拷贝 SQL 文件，也不用担心谁漏了哪个字段。更爽的是，迁移还有回滚功能，改错了直接撤回，比手动改表安全一万倍。我见过太多人因为手抖删了关键字段，然后满世界找备份，那场面真叫惨烈。
Laravel 的迁移文件放在 目录下，命名规则是 。Laravel 会自动按时间戳排序执行，所以你不用担心顺序问题。写迁移其实很简单，用 Schema 门面定义表结构，常用的方法就几个： 新建表， 修改已有表， 删除表。字段类型支持得特别全，字符串、整数、浮点数、布尔值、日期时间、文本、JSON，基本上你能想到的都有，而且还能设置默认值、是否为空、唯一约束等属性。刚开始写的时候，我老记不住语法，经常翻文档，但写了十来个迁移后，基本就顺手了。
有个小技巧我特别想分享：迁移文件的名字一定要写清楚要做什么。比如 、、，光看文件名就知道这个迁移干了什么。别偷懒写 这种模糊的名字，等你有上百个迁移文件时，找文件就会让你崩溃。还有，每个迁移只做一件事，别想着一个文件里既建表又改字段又删索引，那样出了问题，回滚都不知道该回哪一步。我吃过这个亏，所以现在每次写迁移都坚持单一职责原则，哪怕多写几个文件，也比后期排查方便得多。
字段变更这块，Laravel 迁移做得确实贴心。想给已有表加字段，写个新迁移文件，用 方法，然后定义新字段就行。要改字段类型，用 方法，不过得先装 包。删字段更简单， 一行搞定。索引管理也很方便，、、 这些方法都有。我记得有次上线前，产品突然说要给用户表加手机号字段，还要建唯一索引。我写了四行代码，跑了个迁移，前后不到两分钟。要是手动改表，还得写 SQL、考虑不同数据库的兼容性，想想就头大。
外键约束这块，Laravel 迁移也处理得很优雅。你可以在迁移文件里用 方法定义外键，还能指定 和 的行为。比如用户删了，他发的帖子要不要跟着删？订单关闭，关联的支付记录要不要置空？这些逻辑用迁移定义好，数据库层面就能保证数据完整性。不过实话实说，外键在小项目随便用没问题，但大项目要慎重。尤其是高并发场景，外键检查会拖慢性能，很多大厂干脆不用外键，靠业务代码保证数据一致性。所以是否使用外键，得看项目规模和应用场景。
种子数据配合迁移使用，效果翻倍。Laravel 的 Seeder 功能可以在迁移完成后自动插入一些初始数据。比如权限表、配置表、分类表这些基础数据，写个 Seeder，跑一次迁移就全有了。开发环境里，我习惯用工厂模式生成测试数据， 这一行代码就能生成 10 个假用户，字段值都是随机生成的，省去了手动造数据的痛苦。要是哪天测试环境的数据乱了，跑一遍 ，所有表重建，数据重新填充，干净又利索。
说个血的教训：千万别在生产环境跑 或者 。这两个命令会删掉所有表再重建，数据全没了。我有次在测试环境跑顺手了，脑子一抽，在生产环境也跑了一遍，后果？那周我写了三份事故报告，被领导骂了整整一个月。生产环境只能用 ，而且上线前一定要在预发布环境测试一遍。还有，迁移文件提交到版本控制前，最好在本地跑一遍所有迁移，确保不会报错。别问我是怎么知道的，问就是吃过亏。数据库迁移是个好东西，用不好也是把双刃剑，谨慎点总没错。
