手动修改symfony 4.4 doctrine迁移sql会破坏元数据一致性、跨库兼容性、可逆性及团队协作流程，导致状态脱节、执行失败与审计困难。
在 Symfony 4.4 的 Doctrine 迁移脚本里手动修改生成的 SQL（比如直接编辑 migrations/Version*.php 中的 $this->addSql() 语句），会带来多重隐性风险，核心在于破坏了 Doctrine 迁移机制的“元数据一致性”和“可逆性保障”。这不是语法错误问题，而是让迁移从“受控演进”退化为“手工补丁”。
破坏迁移状态与数据库实际结构的映射关系
Doctrine 的 doctrine:migrations:status 和 doctrine:migrations:migrate 都依赖迁移文件内容与数据库当前状态的一致性。一旦你手动改写 SQL：
- 后续
doctrine:migrations:diff可能无法识别你手工添加的字段或约束，因为它只比对实体定义与数据库，不读取你改过的 SQL； - 如果某次迁移中你删掉了自增主键，但实体仍标记
@GeneratedValue，下次 diff 就会生成“加回 autoincrement”的 SQL，而数据库其实已无该行为——造成逻辑错乱； - 多人协作时，别人拉取你的迁移文件，执行后结构与你本地不一致，
doctrine_migration_versions表记录却显示已执行，状态就此脱节。
绕过平台抽象，引发跨数据库兼容问题
Symfony 4.4 + Doctrine 默认通过 DBAL 层屏蔽数据库差异（如 MySQL 的 AUTO_INCREMENT vs PostgreSQL 的 SEQUENCE）。手动写 SQL 直接暴露底层语法：
- 在 MySQL 迁移里写
MODIFY COLUMN name VARCHAR(255) NOT NULL，迁移到 PostgreSQL 就报错； - 用
ENGINE=InnoDB或USING btree等引擎/索引特有语法，导致其他环境无法执行； - PostgreSQL 下忘记给序列名加双引号（
"my_table_id_seq"），大小写敏感导致后续查询失败。
丧失可逆性与幂等性保障
Doctrine 迁移默认要求 up() 和 down() 成对、可逆。手动改 SQL 往往只动 up()，忽略 down() 同步更新：
- 你在
up()里加了一个唯一索引，但down()没删——回滚失败； - 手动插入测试数据（
INSERT INTO user...），down()却没做DELETE，导致反复迁移时主键冲突； - SQL 中用了变量或函数（如
NOW()、DEFAULT CURRENT_TIMESTAMP），不同数据库解释不同，同一迁移在 dev/staging 环境行为不一致。
干扰自动 diff 与团队协作流程
当项目启用 doctrine:migrations:diff 自动检测变更时，手工 SQL 会让工具“看不懂”你的意图：
- 实体新增一个
@Column(type="json")字段，diff 生成标准 DDL；但你之前手工在迁移里写了ADD COLUMN data TEXT并加了 JSON 解析逻辑——diff 不会覆盖它，也不会警告冲突； - CI/CD 流水线执行
doctrine:migrations:migrate --no-interaction，若手工 SQL 含交互式提示（如注释掉某行）或条件判断，可能静默跳过关键步骤； - 审计时无法追溯“这个字段为什么是 TEXT 而不是 JSON 类型”，因为源头不在实体，而在某次被修改过的迁移文件里。
