各位小伙伴都是怎么使用migrate的？

这正是 migrate 的作用，将数据表的改动也能纳入版本控制。随时 migrate 就可以。

为何我使用 migrate 没有出现你所说的情况

可能还是你对 文档 或者 使用 不是很熟悉

只要当前开发任务还没有部署到正式服务器，那么，开发的时候 migration文件可以随便改，没必要在本地创建多个迁移文件，上线后就没办法了。

migration的作用就是跟踪各种变化啊 正式发布可以备份原来的migration文件夹 用下面的工具重新按照每个数据表生成全新的migration文件 github.com/kitloong/laravel-migrat...

如果需要修改的表还在开发中，那么直接修改table的migration文件，rollback之后重新migrate就行。如果是修改生产环境中已经存在的表表结构，那么新建单独的字段migration文件做表结构改动。

每次改结构都创建一个迁移文件。

线上改数据库字段?

不是因为怕出问题(小项目不考虑那些规范),是我健忘…

我不会想起 线上 要改数据库结构。

线上 执行下迁移就改变数据库结构了。
(不可否认: 迁移确实比直接改更麻烦 但是也解决 健忘)

开发过程

表结构确实会经常变动，尤其是因为前期设计考虑不周到、需求变化等原因，migrate 可以更轻松的改表、撤销，直到最终表结构稳定。

生产环境

在生产环境直接执行 migrate 命令还是有点心虚，另外也不方便监管。我现在的做法：将 migration 文件和 --pretend 生成的 SQL （微调后的）都提交到版本管理。之所以保存 SQL 是因为很多时候 migrate 生成的 SQL 并不是特别符合要求（比如表注释、字段编码等）。

如果是多人协作，SQL 还会附注到 PR 备注，方便伙伴进行 Review。

这正是migrate的作用啊,记录每一次数据库变动，保持数据库的一致性，那如果你说的那种情况没用migrate难道每次导入一遍sql吗？尤其是多人开发 migrate的效果更明显

migrate有点像git的时间线，根据时间来变动，只要不手动去修改数据库的字段，一般是没问题的。当然，如果手动修改数据库的字段，乱了也怪不得别人

migrate就是将数据库和代码一样版本控制

上面有大佬说的很清楚了，我的做法大概就是在第一版开发之前，修改或删除表都是先在原迁移文件进行修改或删除，会告知协同人员使用php artisan migrate:refre进行全量覆盖
投入到使用后，修改或删除都是新建新的迁移文件以便进行增量修改
还有就是支持项目的基础数据会写在数据填充里，也就是一个新项目启动或者是全量覆盖操作之后需要运行 php artisan db:seed进行基础数据填充，比如后台超级管理员账号、后台菜单数据等等

虽然公司一直都是在生产环境用migrate，但是我觉得很虚，哪天要是迁移的时候遇到锁表，就真的非常忧伤了。

在实际当中，是一张表对应一个migrate文件吗？