干我们这一行的，最怕听到的一句话就是：“哎，那个测试库的表结构你改一下，我这边急着用。”你打开数据库管理工具，找到那张表，删掉一列，加个索引，改个字段长度，一气呵成。本地跑通了，代码提交了，然后呢？线上崩了。因为同事的本地库还是老结构，你的代码却已经按新结构写了。这种破事我经历过不止一次，每次都得灰头土脸地去翻binlog，对着生产环境一顿操作，还得跟团队解释半天。后来我学乖了，老老实实把Laravel数据库迁移这套东西用起来，才发现这玩意儿真能救命。
Laravel数据库迁移说白了，就是把表结构的变化写成代码，像管理Git版本一样管理你的数据库结构。你想想，以前我们改表结构靠什么？靠一个叫的文件，放在某个共享文件夹里，谁改了就往上传，然后大家自己手动执行。问题是，谁记得自己执行了哪个文件？谁知道自己漏了哪个文件？反正我是不记得。迁移文件就不一样了，它跟你的应用代码一起进版本库，一起被拉取，一起被执行。你拉下来代码，跑一句，所有该有的表结构变更就自动应用了。
具体怎么用？你得会创建迁移文件。命令很简单，，这个会在目录下生成一个带时间戳的文件。注意这个时间戳，它决定了迁移的执行顺序——Laravel按照文件名里的时间戳从小到大依次跑。所以你要是想在一个已存在的表上加个字段，你得用，这样生成的文件里自动就带上了的代码块，人家知道你是要改表，不是建表。
写迁移代码的时候，有几个坑你得避开。第一个坑是改字段类型。比如你想把类型的字段改成，如果你直接写，大概率报错。为什么？因为Laravel默认的迁移包不支持字段修改，你得先装这个扩展包。装完之后你还得在改字段之前先，把原来的非空约束去掉，然后再改成，不然还是会报错。第二个坑是删字段，这行代码本身没问题，但如果你要删的字段是外键或者有索引，你得先把索引和外键删掉，不然数据库层面直接报错给你看。
版本控制这块，迁移跟Git配合起来才是完全体。每次你改了迁移文件，记得提交到版本库里。同事拉代码的时候，跑一下就完事了。这里有个细节，生产环境部署的时候，你千万别直接跑，因为万一迁移脚本里有问题，你连回滚的机会都没有。正确做法是先跑，它会把要执行的SQL语句打印出来，你检查一遍没问题了再真跑。还有，如果你改了迁移文件内容，但是还没提交，那你自己本地跑一遍，把数据库重置了再重新迁移一遍，确保从零开始能跑通。别觉得麻烦，这能避免很多“我本地能跑啊”的鬼话。
回滚操作也是必学的。会回滚一次批量迁移，回滚最近两次，回滚所有迁移。但说实话，生产环境里我很少用回滚，因为数据都进去了，回滚等于删数据。我更常用的是写方法的时候，把数据恢复的逻辑写进去。比如你加了一个字段，方法里加字段，方法里删字段，这没问题。但如果你在方法里给所有用户都设了，那方法最好把默认值也处理一下，不然字段删了再重新迁移，数据就乱了。
进阶一点，你还可以用来配合迁移。表结构建好了，总得有初始数据吧？，然后在里调用它，跑就能把初始数据塞进去。这里有个技巧，这个命令能把数据库从头到尾重建一遍，顺便把初始数据也灌进去。这个在开发环境特别好用，每次拉完代码跑一遍，数据库就是最新状态，不用手动去执行一堆SQL脚本。
说说跟团队协作的注意事项。第一，永远不要在迁移文件里写死数据操作，比如，这种操作应该放到里。为什么？因为迁移文件的执行顺序是固定的，你在这个文件里插入的数据，可能在下一个迁移文件里就被改掉了，到时候你根本不知道数据跑到哪去了。第二，迁移文件一旦提交被大家拉取了，就别再改了。哪怕你发现写错了，也别改原文件，而是新建一个迁移文件去修正。这跟Git提交一样，历史记录不可篡改，你改了旧文件，别人拉代码的时候迁移就乱了。第三，别忘了在生产环境跑迁移之前备份数据库，这年头谁还没个操作失误的时候，备份了才有后悔药吃。
Laravel数据库迁移这东西，刚开始用觉得麻烦，多写几个文件而已，还得装扩展包，还得注意各种细节。但用久了你就发现，它把数据库结构管理从“人肉记忆”变成了“代码版本控制”，这才是真正的工程化。表结构变成了代码，代码进了Git，Git有历史记录，有分支，有合并，那数据库结构自然也就有了版本管理。以后再有人跟你说“我改了下表结构，你手动执行下这个SQL”，你就直接把迁移文件甩给他，让他跑。省心，省事，还省得背锅。
