phinx的init命令仅生成空配置文件phinx.yml和migrations目录，create命令只生成带时间戳的空迁移文件骨架，不分析现有表结构，所有sql逻辑需手动编写。
Phinx 的 init 和 create 命令到底在干啥
Phinx 不会自动读取项目里已有的数据库结构，init 只是生成一个空的 phinx.yml 配置文件和 migrations/ 目录；create 也只是按模板生成一个带时间戳前缀的空迁移文件，比如 20240510123456_create_users_table.php。它不分析表、不推断字段，所有逻辑得你手写。
常见错误是以为运行 create users 就能自动生成建表语句——其实它只生成骨架，里面 change 方法还是空的。你得自己填 $table->addColumn('name', 'string') 这类调用。
实操建议：
- 配置
phinx.yml时，paths.migrations必须是相对路径（如%%PHINX_CONFIG_DIR%%/db/migrations），不能写绝对路径，否则phinx migrate会报Directory does not exist - 时间戳命名不能手动改——Phinx 依赖它排序执行顺序，重命名会导致跳过或重复执行
- 如果已有表，别硬写
createTable，优先用create+ 手动补insert或execute("INSERT ...")做数据初始化
Laravel Migrate 的 php artisan migrate:refresh 为什么删库又不重建
这个命令本质是先跑所有 down()，再跑所有 up()。但它只对「已记录在 migrations 表里的版本」生效。如果你中途手动删过某条记录，或者新增了没执行过的迁移文件，refresh 就会漏掉它——不是“删库”，而是只回滚它知道的那些。
立即学习“PHP免费学习笔记（深入）”；
更麻烦的是：如果某个 down() 方法写成 Schema::dropIfExists('users')，但对应 up() 里没建，那 refresh 后表就真没了，且不会报错。
实操建议：
- 本地开发可加
--seed一起重跑测试数据，但生产环境禁用refresh，只允许migrate或migrate:fresh --force（需确认 DB 是空的） -
down()方法别偷懒全写drop，尽量和up()对称，比如addColumn对应dropColumn，避免破坏结构一致性 - 执行前先看
php artisan migrate:status，确认哪些已跑、哪些 pending，比盲跑安全得多
Phinx 和 Laravel Migrate 共存时，migrations 表冲突怎么办
Phinx 默认用 phinxlog 表记录执行历史，Laravel 用 migrations 表。如果两个工具往同一个库混用，且都试图管理同一组变更，就会出现「Laravel 认为某迁移没跑过，Phinx 却说跑过了」这类状态错乱。
根本原因不是表名冲突，而是两者对「迁移是否完成」的判定逻辑完全不同：Phinx 看 phinxlog.version 时间戳，Laravel 看 migrations.migration 文件名字符串。哪怕内容一样，它们也互不认账。
实操建议：
- 一个项目只选一种迁移工具，别混用。如果从 Phinx 迁移到 Laravel，先用
phinx rollback -v 0清空全部，再把原迁移逻辑重写成 Laravel 格式，最后手工往migrations表插一条记录标记「基础结构已完成」 - 若必须共存（比如旧模块用 Phinx、新模块用 Laravel），务必分库——物理隔离最省心
- Phinx 的
table_prefix配置不能设成migrations，否则会误删 Laravel 的状态表
迁移文件里写 DB::statement() 或 execute() 的风险点
直接执行原生 SQL 看似灵活，但会绕过 ORM 的方言抽象。比如在 MySQL 里写的 ENGINE=InnoDB，到 PostgreSQL 就直接报错；又比如 SQLite 不支持 ALTER TABLE ... DROP COLUMN，但 Phinx 的 dropColumn 方法内部做了兼容处理，而你手写的 execute("ALTER TABLE ...") 就挂了。
另一个隐形坑：事务。Laravel 的 migrate 默认每个迁移文件在一个事务里，但 DB::statement() 在某些驱动下可能不参与事务（尤其是 DDL 语句）；Phinx 的 execute() 也是同理——MySQL 的 CREATE TABLE 会自动提交事务，导致前面的 INSERT 无法回滚。
实操建议：
- 优先用框架提供的 Schema 构建方法：
Schema::create()、$table->json()等，它们内置了多库适配 - 非写原生 SQL 不可时，先查清楚目标数据库的限制。比如想加索引，别写
CREATE INDEX，改用Schema::table(..., function (Blueprint $table) { $table->index('email'); }) - 涉及 DDL（建表、改列、删索引）的操作，别和 DML（INSERT/UPDATE）写在同一个迁移里，避免事务断裂
