指定版本回滚需执行php bin/console doctrine:migrations:migrate Version20240101AddOrderStatus命令，回滚至该版本之前，要求版本名完全匹配、目标版本已应用且所有前置down()方法可安全运行，并须用--dry-run预览验证。
回滚到指定版本不是“跳转”，而是执行一系列 down() 方法，必须确保目标版本及其之前所有迁移的 down() 都可安全运行，否则会卡住或损坏数据。
怎么指定版本回滚？命令和参数必须匹配状态
Doctrine 不支持“直接跳到 v20240101”，它只接受“回滚到某个版本之前”——即目标版本本身不执行 down()，而是撤销它之后所有已应用的迁移。
-
php bin/console doctrine:migrations:migrate Version20240101AddOrderStatus：回滚到该版本「之前」（即撤销所有比它新的迁移） - 版本名必须完全一致，大小写、下划线、数字都不能错；可用
php bin/console doctrine:migrations:status --show-versions查看当前已应用列表 - 如果目标版本尚未被应用过（比如你打错了名字），命令会报错
No migration found for version "VersionXXX" - 不能用
rollback命令指定版本——doctrine:migrations:rollback只能回退一个，且不接受版本参数
为什么回滚常失败？根源在 down() 方法写得不完整
Doctrine 从不自动推导反向操作。你写了 $schema->createTable('order')，它不会帮你生成 dropTable('order') —— 这个逻辑全靠你手写，而且要覆盖所有依赖路径。
- 常见错误：
down()里删了字段，但另一个迁移又往这张表加了新字段，导致dropColumn()找不到列而报错 - 外键没处理：up() 中加了外键约束，down() 里没先删约束就删字段，MySQL 直接拒绝
- 用了不可逆操作：比如
$schema->getTable('user')->addColumn('password_hash', 'string')后，在down()里只写了dropColumn()，但没考虑已有数据是否允许丢失 - 空
down()或仅含$this->abortIf(true, ...)：等同于声明“此迁移不可回滚”，命令会中断并提示No down() migration implemented
如何验证回滚是否真安全？别跳过 --dry-run
--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，适合需要 DBA 复核的场景 - 确认事务开启：
doctrine_migrations.yaml中必须有transactional: true，否则单条 SQL 失败不会回滚整个操作
回滚完成后必须立刻核对状态和结构
控制台显示 “Successfully migrated” 并不等于数据库已回到预期状态——很多问题只在后续请求中暴露。
- 立即运行
php bin/console doctrine:migrations:status，检查Current Version是否等于目标版本前一个，且Executed列表已剔除目标版本之后的所有项 - 手动连库查表：
DESCRIBE order;看字段是否已移除，SHOW CREATE TABLE order;看约束是否清理干净 - 如果项目启用了 Doctrine Schema Validator，跑一次
php bin/console doctrine:schema:validate，它会指出实体注解和当前 DB 结构的差异 - 特别注意时间敏感字段（如
created_at默认值）、索引、主键变更——这些在--dry-run中可能不显眼，但影响查询行为
最易被忽略的一点：回滚只改结构，不碰数据。如果你在某次迁移里执行了 INSERT 或 UPDATE（比如初始化配置），这些操作不会被自动撤销——down() 必须显式写反向 SQL，否则数据残留会破坏后续逻辑。
