Laravel迁移文件通过严格匹配YYYY_MM_DD_HHIISS_*.php格式识别，并按时间戳升序排序执行；若时间戳重复则按字母序fallback，导致顺序不可控，故禁止手动修改已生成文件的时间戳或重命名。
迁移文件怎么被识别和排序
Laravel 不是靠文件名“看起来像迁移”就执行，而是严格匹配 YYYY_MM_DD_HHIISS_*.php 格式（如 2019_12_14_000001_create_personal_access_tokens_table.php）。只要在指定路径下满足该命名规则，无论来自 database/migrations/、Modules/Admin/Database/Migrations/ 还是 vendor/ 发布的迁移，都会被扫描并纳入执行队列。
排序完全依赖文件名前缀的时间戳——升序排列。这意味着：哪怕你手动改了文件名里的日期，或者把两个迁移时间戳设成一样，Laravel 就会按字母顺序 fallback 排，结果不可控；一旦时间戳乱序，up() 执行顺序就错，down() 逻辑可能失效。
- 不要重命名已生成的迁移文件
- 避免手动生成相同时间戳的多个文件（比如复制粘贴后只改描述）
-
make:migration自动生成的时间戳基于当前 UTC 时间，确保唯一性
migrate 命令到底做了什么
php artisan migrate 的核心动作只有三步：查表、排序、执行。它读取数据库中 migrations 表，对比本地所有匹配格式的迁移文件，找出那些 migration 字段值未记录在表中的文件，再按时间戳排序，逐个调用其 up() 方法，并在成功后向 migrations 表插入一条记录（含 batch 编号）。
关键点在于：它不校验文件内容哈希，也不检查 PHP 类是否真正实现了 up() ——只要文件能被 require，且类里有 up() 方法，就执行。所以：
- 如果某个迁移执行中途报错（如字段长度超限），
migrations表里可能只写入了前面几个，后续再跑migrate会跳过已记录项，但卡住的那个不会自动重试 -
migrate:fresh会先删表（跳过migrations和failed_jobs），再重新扫描全部迁移文件、全部执行，不管之前有没有记录 -
--path参数本质是告诉底层Migrator“只扫这个目录”，module:migrate Admin就是把--path=Modules/Admin/Database/Migrations透传给原生命令
为什么不能改已执行的迁移文件
因为 Laravel 迁移机制没有 checksum 校验，但它依赖“一次编写、多次执行”的幂等假设。你改了已执行过的迁移文件的 up()，其他环境首次运行时就会按新逻辑执行——比如加了个字段，结果发现表里已经存在同名字段，直接报错 SQLSTATE[42S01]: Base table or view already exists。
更隐蔽的问题是 down()：原始迁移删表，你后来改成删字段，回滚时就会漏掉字段或误删整表。
- 修正错误必须新建迁移，例如加字段用
add_phone_to_users_table，改字段类型需doctrine/dbal支持并单独建迁移 - 哪怕只是调整注释或空格，也别碰已提交到 Git 的旧迁移文件
- 生产环境禁止
migrate:fresh，它清空所有业务表，不是“重跑一遍”，而是“先删再建”
batch 是什么，rollback 怎么工作
batch 是 Laravel 给每次 migrate 调用分配的自增编号，同一命令执行的所有迁移共享同一个 batch 值。例如你一次跑了 3 个新迁移，它们在 migrations 表里 batch 都是 5。
php artisan migrate:rollback 默认回退最后一批（即 batch = MAX(batch)），执行这批里所有迁移的 down() 方法。它不是按时间戳倒序一条条撤，也不是撤销 SQL，而是调用对应类的 down()。
- 想只回退某一个迁移？得确保它是该 batch 唯一成员，否则
--step=1仍会撤整批 -
migrate:reset是回退所有 batch，从头清空 - 批量回滚依赖
down()正确实现：删表要用Schema::dropIfExists()，而不是Schema::drop()，避免表不存在时报错中断
Migrator 怎么扫描文件，但一旦模块路径没配对、或时间戳人工干预过，问题就出在“看起来应该没问题”的地方。 
