composer安装doctrine/migrations提示版本冲突，因该包对php、doctrine/dbal及doctrine/orm有严格版本约束；需根据php和依赖版本显式指定兼容的migrations版本，如php 7.4用^3.5，php 8.0+配dbal 3.x用^3.7。
Composer 安装 doctrine/migrations 时为什么提示版本冲突？
直接运行 composer require doctrine/migrations 很可能失败，因为 doctrine/migrations 对 PHP 版本、doctrine/dbal 和 doctrine/orm（如果已用）有严格约束。常见报错如：doctrine/dbal 3.7.0 requires php ^8.0，而你的项目还在 PHP 7.4。
解决方法不是硬升 PHP，而是显式指定兼容版本：
- PHP 7.4 项目：用
composer require doctrine/migrations:^3.5（对应 DBAL 2.x） - PHP 8.0+ + DBAL 3.x：用
composer require doctrine/migrations:^3.7 - 若已装
doctrine/orm，先查它的composer show doctrine/orm，再选与之匹配的 migrations 版本（例如 ORM 2.13 要求 migrations ^3.5）
生成 migration 文件时 migrate:diff 报错 “No metadata found”
这个错误本质是 Doctrine 不知道该对比哪套实体定义——它默认从 doctrine.orm.mappings 或注解/Attribute 扫描实体类，但没配置路径或命名空间就找不到任何 @Entity。
检查两件事：
- 确认
config/doctrine.yaml（或doctrine.yaml）里doctrine.orm.mappings正确指向实体目录，例如：paths: ['%kernel.project_dir%/src/Entity'] - 实体类必须带
#[Entity]（PHP 8.0+）或@Entity（PHP - 如果用 XML/YAML 映射，确保
mappings中启用了对应驱动：type: xml且dir指向正确
执行 php bin/console doctrine:migrations:migrate 总卡在 “Executing” 阶段
这不是卡住，而是迁移类里的 up() 方法没写 $this->addSql() 或调用了未定义的表名。Doctrine 默认不自动推导 SQL，所有 DDL/DML 必须显式声明。
典型陷阱：
-
$this->addSql('CREATE TABLE user (...)');中表名写成users，但实体映射里是@Table(name="user")—— 名字不一致导致后续查询失败 - 在
up()里调用$this->connection->executeStatement()却忘了返回值或异常处理，migration 会静默失败 - 使用
doctrine/migrationsv3+ 后，AbstractMigration::up()参数从Schema改为SchemaProviderInterface，旧写法$schema->createTable()直接报错
如何安全地回滚一个已执行的 migration？
doctrine:migrations:rollback 只能撤回**最后一条**，且要求该 migration 的 down() 方法存在并有效。很多人写了 up() 却漏掉 down()，或者 down() 里 SQL 写错（比如删表却没加 IF EXISTS）。
实操建议：
- 每次生成 migration 后，立刻补全
down()，哪怕只是反向操作：$this->addSql('DROP TABLE user');→$this->addSql('CREATE TABLE user (...)'); - 生产环境禁止用
rollback，改用新 migration 修复（例如加字段错了，就写个新 migration 删掉它） - 想撤多条？用
doctrine:migrations:execute --down {version}指定目标版本，但必须确保中间每条down()都可逆
真正麻烦的是带数据迁移的操作（比如 UPDATE 某列值），down() 很难 100% 还原，这类逻辑最好拆到命令行脚本里，别塞进 migration。
