旧项目迁移本质是“对齐现状”，非“重建起点”；必须执行doctrine:migrations:status校验、schema:validate验证及dump-sql比对，确认实体映射、迁移文件路径与数据库实际结构一致，否则易致迁移失败或数据丢失。
不是等同，而是起点相似、路径不同。旧项目迁移不能简单照搬新项目初始化流程，否则容易跳过关键兼容性检查和历史状态处理。
必须区分“初始化”和“迁移”的本质差异
新项目从零开始，配置干净、无历史迁移记录、无存量数据；旧项目已有实体、已执行的迁移版本、可能存在的自定义SQL或Schema操作，甚至存在被手动修改过的表结构。直接套用全新配置，会触发 Doctrine 元数据与数据库实际结构的不一致，导致 make:migration 生成空文件、migrate 报错或静默跳过。
旧项目迁移前的强制校验步骤
- 运行
php bin/console doctrine:migrations:status，确认当前数据库状态是否与doctrine_migration_versions表记录一致；若显示 “10 migrations have no execution status”，需先执行php bin/console doctrine:migrations:sync-metadata-storage同步元数据 - 执行
php bin/console doctrine:schema:validate --skip-sync，检查实体映射是否仍能被 Doctrine 正确识别（避免因命名空间变更、注解遗漏或自动扫描路径失效导致“no metadata”） - 检查
migrations/目录下所有Version*.php文件是否可被自动加载：类名必须严格匹配文件名（如Version20230101000000.php→Version20230101000000），且命名空间为DoctrineMigrations（Symfony 6.2+ 默认使用App\Migrations，需在doctrine_migrations.yaml中显式配置namespace: App\Migrations）
配置复用但需针对性调整
-
.env中的DATABASE_URL必须指向当前环境真实可用的数据库，不能直接复制开发环境配置到生产环境（尤其注意 SQLite 路径权限、MySQL 用户权限、Docker 容器网络 host） -
config/packages/doctrine.yaml需核对doctrine.dbal.url是否未被硬编码覆盖；若旧项目使用 YAML/XML 映射而非注解，要确保mappings下包含对应路径且is_bundle设为false -
config/packages/doctrine_migrations.yaml中的dir_name必须与实际迁移文件存放路径一致（旧项目可能为src/Migrations，新项目默认为migrations/），否则migrate命令找不到待执行文件
迁移过程不能省略“比对验证”环节
生成迁移前，务必运行一次 php bin/console doctrine:schema:update --dump-sql。如果输出为空，说明 Doctrine 认为结构已同步——此时不应直接 make:migration，而应检查：
- 实体类是否仍被
auto_mapping: true扫描到（php bin/console debug:config doctrine查看entity_managers.default.mappings） - 是否存在已被删除但未清理的旧迁移文件（残留空
up()方法会干扰 diff 逻辑） - 数据库中是否存在 Doctrine 不识别的手动建表（如通过 phpMyAdmin 创建的表），这类表会被忽略，但可能影响后续关联字段生成
旧项目迁移的核心是“对齐现状”，不是“重建起点”。跳过校验直接套用新配置，大概率导致迁移失败、表缺失或数据丢失。
