phinx是php项目数据库迁移最稳妥选择：轻量、框架无关、命令行驱动、迁移文件为标准php类且回滚可控；应避免直接git管理schema.sql，须用phinx create生成迁移并优先使用其抽象方法。
用 phinx 管理 PHP 项目的数据库迁移脚本最稳妥
直接上结论：PHP 项目里做数据库版本控制，phinx 是目前最轻量、兼容性最好、且不绑定框架的选择。它不依赖 Laravel 或 Symfony 的整套生态，纯命令行驱动，生成的迁移文件是标准 PHP 类，逻辑清晰，回滚可控。
常见错误是拿 Git 直接管理 schema.sql 文件——改字段、加索引、删表全靠手写 SQL，没有执行顺序、无法自动回退、多人协作时极易冲突。
实操建议：
- 安装：
composer require --dev robmorgan/phinx，然后运行vendor/bin/phinx init生成phinx.php - 配置数据库连接时，别把密码硬编码进
phinx.php，改用getenv('DB_PASSWORD')+.env文件（用vault或vlucas/phpdotenv加载） - 每次变更数据库结构，必须用
vendor/bin/phinx create AddUsersEmailIndex生成新迁移类，而不是手动新建 PHP 文件 -
up()和down()方法里，优先用 Phinx 提供的抽象方法（如$table->addColumn('email', 'string', ['limit' => 128])），少写原生 SQL；只有涉及函数、视图、存储过程时才用$this->execute()
为什么不用 doctrine/migrations？
Doctrine 迁移工具功能强，但对纯 PHP 项目太重：它强依赖 Doctrine DBAL，初始化要配 connection 实例，还要求你提前定义实体或 YAML 映射。一旦项目没用 ORM，光为迁移动手搭 DBAL 配置，就容易在 DriverManager::getConnection() 报错。
立即学习“PHP免费学习笔记（深入）”；
典型卡点：
-
InvalidArgumentException: The given connection is not configured correctly.—— 往往因为driver写成pdo_mysql而不是mysql - 迁移类命名必须严格匹配
Version20230401120000格式，否则doctrine:migrations:status识别不了 - 回滚单条迁移要用
--version=20230401120000，不能只写短哈希，参数容错低
生产环境执行迁移前必须验证的三件事
本地跑通不等于线上安全。数据库结构变更一旦出错，可能锁表、丢数据、阻塞请求。
上线前检查清单：
- 确认目标库的
phinxlog表存在且可写（vendor/bin/phinx migrate -e production第一次会自动建） - 用
vendor/bin/phinx status -e production对比当前环境和代码里的 migration 列表，看哪些未执行、哪些已执行 - 如果是 DDL 变更（如
ALTER TABLE），先在从库或测试库用pt-online-schema-change模拟执行，观察是否触发长事务或复制延迟
团队协作时迁移文件命名和提交的潜规则
多人同时开发时，phinx 不会自动合并迁移顺序。两个开发者各自 create 出来的时间戳一样，就会冲突。
解决办法很实际：
- 所有迁移文件名末尾加作者缩写，例如
20240520143000_add_status_to_orders_jw.php（jw是人名） - Git 提交前，先
git pull，再vendor/bin/phinx status看有没有新迁移没拉下来；如果有，先migrate再继续自己的变更 - 绝不允许一个迁移类里混写多个不相关的变更（比如既加字段又删索引），每个逻辑独立的 DDL 应该对应一个迁移文件
最常被忽略的是：迁移类里的 change() 方法看似方便，但它无法支持所有操作（比如修改列类型在某些 MySQL 版本会失败），所以老老实实用 up()/down() 更可控。
