核心问题是down()方法不可逆或逻辑错误，如忽略索引删除、字段已删仍执行drop column、未处理数据变更反向操作；其次为迁移状态表与实际结构脱节、ddl隐式提交、平台配置偏差导致diff失准。
Symfony 3 中数据库模型事务回滚失败，核心问题往往不在 Doctrine 本身“坏了”，而是事务逻辑、迁移设计或环境配置与预期不一致。下面几个原因最常见、也最容易被忽略。
down() 方法逻辑不完整或不可逆
Doctrine 迁移的回滚成败完全取决于你写的 down() 方法是否真正可逆。很多开发者只专注写 up()，却把 down() 留空或写得过于简单。
- 在 up() 中加了唯一索引，但 down() 只删表，没删索引 → 回滚时因索引依赖报错
- up() 新增字段 A，down() 写了 DROP COLUMN A，但该字段其实在上一次迁移中已被删 → SQL 执行失败
- 用
$this->addSql('DROP TABLE IF EXISTS xxx')→ 某些 MySQL 版本下 Doctrine 不解析IF EXISTS，应改用显式判断或分步处理 - 迁移中含数据变更（如 INSERT/UPDATE），down() 却没写对应 DELETE 或 UPDATE 回原值 → 数据残留，看似“回滚成功”，实则状态不一致
迁移状态表与实际结构脱节
Doctrine 依靠 doctrine_migration_versions 表记录哪些迁移已执行。一旦这张表和数据库真实结构不匹配，回滚就会失效或报 “No migrations to execute”。
- 迁移文件被误删或重命名，但表里仍有对应版本记录 → Doctrine 认为该迁移“存在”，执行
rollback时找不到类，直接失败 - 手动执行过 SQL（比如用 phpMyAdmin 建表），但没走迁移流程 → 下次
migrate会重复建表，报 “Table already exists”；而rollback因无对应 down() 无法清理 - 多环境共用一个数据库（如本地连了测试库），别人跑了迁移你没同步文件 →
status显示 “up to date”，但结构早已变化，回滚目标错位
事务边界被隐式提交破坏
即使不是用迁移命令，而是手写模型层事务（如 EntityManager::transactional()），也可能因底层行为导致回滚失效。
- 在事务中执行 DDL 语句（如
CREATE INDEX、ALTER TABLE）→ 多数数据库会触发隐式提交，后续ROLLBACK对之前操作无效 - 使用了不支持事务的存储引擎（如 MySQL 的 MyISAM 表）→
ROLLBACK完全不生效，所有写入立即持久化 - 连接配置开启自动提交（
AUTOCOMMIT=1），或未设置PDO::ATTR_ERRMODE = PDO::ERRMODE_EXCEPTION→ 异常不抛出，rollback()根本没机会调用
环境与平台配置引发比对偏差
Symfony 3 使用 Doctrine DBAL 做 schema 推导，不同数据库平台对相同注解解释不同，会导致 diff 和迁移生成错误 SQL，进而让 down() 失效。
- PostgreSQL 实体用了
options={"autoincrement":true}→ 该配置仅 MySQL 有效，PostgreSQL 忽略，但 DBAL 仍参与 diff，造成前后两次迁移逻辑矛盾 - 用
strategy="SEQUENCE"却没指定sequenceName→ Doctrine 猜序列名，猜错后下次 diff 会“纠正”回普通整型列，down() 按错路径删序列，失败 - 实体字段没声明
length，而数据库里是VARCHAR(255)→ DBAL 推导长度不一致，diff 生成改类型语句，down() 若没适配就崩 - PostgreSQL 表名大小写敏感：实体写
@ORM\Table(name="User")，但实际表名是user→ schema 比对失败，迁移无法正向/反向执行
