symfony 4 迁移本身不操作业务数据，但执行 doctrine:migrations:migrate 时若 sql 变更涉及 drop column、alter table ... type 或 truncate 类操作，就可能引发数据丢失；真正风险在于迁移文件生成逻辑、环境状态错位和人为干预环节。
Symfony 4 迁移本身不操作业务数据，但执行 doctrine:migrations:migrate 时若 SQL 变更涉及 DROP COLUMN、ALTER TABLE ... TYPE 或 TRUNCATE 类操作，就可能引发数据丢失。真正风险不在命令本身，而在迁移文件生成逻辑、环境状态错位和人为干预环节。提前识别并切断这几个关键断点，就能大幅降低意外。
确认实体与数据库结构真实一致
Doctrine 的 diff 机制只比对它“知道”的部分，很多字段差异它根本看不见。比如：
- PostgreSQL 中
@ORM\Column(options={"autoincrement":true})被完全忽略，但实体若漏写strategy="IDENTITY"，diff 可能误判为“该列不该自增”，后续迁移就悄悄删掉默认值 - MySQL 表用了
ENGINE=MyISAM，而 Doctrine 默认按 InnoDB 推导，类型推断偏差会导致TEXT→LONGTEXT等隐式变更 - 字段加了
@ORM\Column(length=191)，但数据库里是VARCHAR(255)，diff 不报错也不修正，直到某次changeType操作触发截断
建议每次改实体后，先运行 php bin/console doctrine:schema:update --dump-sql，人工核对输出是否符合预期；再用 --force（仅限开发环境）同步一次，确保底层结构和元数据对齐。
禁止在迁移文件中写数据操作逻辑up() 方法里混入 PHP 循环处理百万行数据，或手写 $this->addSql('UPDATE users SET status = 1 WHERE id ，看似方便，实则危险：
- 迁移事务默认开启，大更新容易锁表超时，失败后回滚不彻底
-
down()几乎无法安全逆向（比如 UPDATE 后怎么精准还原旧值？） - CI/CD 流水线里一旦出错，重试会重复执行，导致数据翻倍或错乱
正确做法是把数据迁移拆成独立命令：
- 新建
app:fix:status-update命令类，支持分批、带进度、可中断 - 在部署流程中单独调用，不和结构迁移耦合
- 执行前备份相关表，留退路
严格校验迁移状态表与文件一致性doctrine_migration_versions 表记录哪些版本已执行，但它和磁盘上的迁移文件不是强绑定的。常见脱节场景：
- 开发者手动
ALTER TABLE修改了结构，但没生成对应迁移文件，也没更新状态表 - 多人协作时，A 生成了
Version20260730.php并提交，B 拉取代码却没执行，本地 status 显示 “Not executed”，但数据库其实已有该结构 - 文件被误删或重命名，状态表里还记着，下次 migrate 就报错卡住
上线前务必执行：
-
php bin/console doctrine:migrations:status，确认 “Executed migrations” 列表与migrations/目录下文件名完全匹配 - 若发现状态表多出记录，用
php bin/console doctrine:migrations:version <version> --delete</version>安全清理（不要直接删表） - 生产环境首次部署前，用
--dry-run模式预演，看实际要执行哪些 SQL
生产环境迁移必须加防护参数
默认命令缺乏容错设计，几个关键开关不能省：
-
--no-interaction：避免交互式确认阻塞自动化部署 -
--allow-no-migration：防止无新迁移时返回非零退出码，导致流水线误判失败 -
--timeout=300：给大表ADD COLUMN或索引重建留足时间，避免被系统 kill -
--env=prod：强制加载生产配置，避开 dev 环境的调试日志或缓存干扰
另外，.env 中 DATABASE_URL 必须指向目标库，且用户权限至少包含 SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, DROP；用 php bin/console doctrine:database:create --if-not-exists 先验证连通性，比等到 migrate 报错再排查快得多。
