断电导致 symfony 4 迁移中断时，应先检查 doctrine_migration_versions 表状态、验证数据库 schema 一致性，再根据迁移是否部分执行选择补录版本记录、删除 null 记录或手动修复，所有操作前必须备份数据库。
断电导致 Symfony 4 迁移中断，关键不是重跑 php bin/console doctrine:migrations:migrate，而是先判断迁移是否已部分提交、数据库状态是否一致、文件系统是否受损。盲目重试可能造成表结构错乱、数据不一致甚至元数据损坏。
立即停用写入，确认当前迁移状态
断电后不要重启服务或再次执行 migrate 命令。先登录数据库，检查迁移表（默认 doctrine_migration_versions）最后一条记录：
- 如果最新记录的
version对应的是你刚中断的迁移号，且executed_at非空 → 说明该迁移已成功提交，只是 Symfony 缓存/命令行未返回结果；此时只需清缓存并验证应用行为。 - 如果该版本存在但
executed_at为NULL→ 表示 migration 类已加载但事务未提交，需人工检查该迁移 SQL 是否实际执行（查表结构变更、新增字段、索引是否存在）。 - 如果该版本在表中不存在 → 迁移尚未写入版本表，但部分 SQL 可能已执行（尤其含多条语句且无事务包裹时），必须比对 schema 和 migration 文件内容。
验证数据库结构与代码定义一致性
运行以下命令生成当前 DB 实际结构快照，并与迁移预期比对：
-
php bin/console doctrine:schema:create --dump-sql（仅输出 SQL，不执行）→ 查看是否报错或输出非空，反映 schema 不一致 -
php bin/console doctrine:schema:validate→ 检查实体映射与 DB 实际结构是否匹配，重点看 “The mapping files are correct.” 和 “The database schema is in sync.” 两条是否都为 OK - 若提示不一致，用
php bin/console doctrine:schema:update --dump-sql查看差异，再对照中断的 migration 文件中的up(Schema $schema)方法，逐条确认哪些 DDL 已生效
修复迁移状态与清理残留
根据验证结果选择处理方式，所有操作前务必备份数据库（mysqldump 或 pg_dump）：
- 若迁移已部分执行但未记入版本表：手动补录记录，如
INSERT INTO doctrine_migration_versions (version, executed_at) VALUES ('20230101120000', NOW());（替换为实际版本号），再清 Symfony 缓存 - 若迁移未执行但版本表有 NULL 记录：删除该行，再重新运行 migrate（确保 migration 文件未被修改）
- 若 migration 执行出错导致表损坏（如中途失败的 ALTER TABLE）：用
php bin/console doctrine:migrations:sync-emergency（Symfony 4.4+）或手动回滚对应 SQL，再标记为已执行 - 避免使用
--force或跳过校验参数，它们会掩盖真实不一致
预防下次迁移中断风险
断电不可控，但可降低影响范围：
- 迁移脚本尽量保持幂等：每个
up()方法内只操作单个表，避免跨表事务；复杂逻辑拆分为多个小迁移 - 生产环境迁移前，先在相同结构的测试库完整跑一次，并启用
doctrine.dbal.logging: true记录所有 SQL - 部署流程中加入 pre-migration 备份步骤（如
mysqldump --single-transaction），而非依赖 nightly 备份 - 服务器配备 UPS，Linux 系统启用
systemd-journald持久日志，便于事后追溯断电时刻的 migration 进程状态
