doctrine迁移回滚是执行目标版本之后所有已应用迁移的down()方法，而非撤销单次操作；需用php bin/console doctrine:migrations:migrate versionxxx指定完全匹配的已应用版本名，并务必通过--dry-run预览sql验证安全性。
回滚 Doctrine 迁移不是“撤销上一次”，而是“退回到某个版本之前”，必须明确目标版本、验证 down() 方法安全性，并始终用 --dry-run 预览 SQL。
怎么指定版本回滚？命令必须匹配已应用状态
Doctrine 不支持 “跳到 v20240101”，只支持 “回滚到 Version20240101AddOrderStatus 之前”——即执行该版本之后所有已应用迁移的 down() 方法，而目标版本本身不执行 down()。
-
php bin/console doctrine:migrations:migrate Version20240101AddOrderStatus：回滚至该版本「之前」（撤销所有比它新的迁移） - 版本名必须完全一致：大小写、下划线、数字一个都不能错；可用
php bin/console doctrine:migrations:status --show-versions查看已应用列表 - 若目标版本从未被应用过（比如拼错），会报错
No migration found for version "VersionXXX" -
doctrine:migrations:rollback只能回退一个，且不接受版本参数，别用它指定版本
为什么 down() 方法常失败？根源在手动逻辑缺失
Doctrine 从不自动推导反向操作。你写了 $schema->createTable('order')，它不会帮你生成 dropTable('order')——全靠你手写，且必须覆盖所有依赖路径。
- 删字段前没检查是否存在：另一个迁移往同表加了新字段，
dropColumn()找不到列就报错 - 外键没处理：up() 中加了外键约束，down() 里没先
dropForeignKey()就删字段，MySQL 直接拒绝 - 用了不可逆操作：比如
addColumn('password_hash', 'string')后，down()只写dropColumn()，但没考虑已有数据是否允许丢失 - 空
down()或仅含$this->abortIf(true, ...)：等同于声明“此迁移不可回滚”，命令中断并提示No down() migration implemented
如何安全验证回滚？必须用 --dry-run 看真实 SQL
--dry-run 输出的 SQL 是唯一能提前暴露问题的地方，尤其在生产环境，它比实际执行更关键。
-
php bin/console doctrine:migrations:migrate Version20240101AddOrderStatus --dry-run：列出将执行的所有 SQL - 重点检查是否有
DROP TABLE、ALTER TABLE DROP COLUMN等高危语句 - 输出为空 ≠ 成功：说明目标版本已是当前版本，或它之后没有已应用迁移——此时命令无实际效果
- 可导出 SQL 到文件再人工审计：
php bin/console doctrine:migrations:migrate first --write-sql rollback.sql（注意：first是占位符，实际要替换成目标版本）
回滚失败后最常被忽略的点
回滚卡住时，90% 的情况不是命令不对，而是某次迁移的 down() 方法里漏掉了对关联表、索引或序列的操作；PostgreSQL 用户尤其要注意旧 SEQUENCE 残留问题——比如 ID 改用 strategy="IDENTITY" 后，必须手动 DROP SEQUENCE IF EXISTS your_table_id_seq CASCADE，否则后续 diff 和 migrate 都可能误判结构差异。
