DoctrineFixturesBundle未启用导致命令找不到，需composer安装并配置bundles.php；load()中persist后必须调用flush()；依赖顺序需通过DependentFixtureInterface声明；原生SQL或服务注入应改用FixtureInterface。
Command “doctrine:fixtures:load” not found 是 bundle 没启用
运行 bin/console doctrine:fixtures:load 报错“Command not found”，不是命令拼错了，而是 DoctrineFixturesBundle 根本没注册进容器。Symfony 5.4+ 默认不带这个包，必须手动装且启用。
执行：composer require --dev doctrine/doctrine-fixtures-bundle
然后检查 config/bundles.php 是否有这一行：Doctrine\Bundle\FixturesBundle\DoctrineFixturesBundle::class => ['dev' => true, 'test' => true]
- 如果用了 Symfony Flex，通常会自动加；但升级旧项目或删过配置时容易漏掉
- 只
require了包却不启用 Bundle，bin/console list里根本看不到 fixtures 命令 - CI 环境报
Class XXX not found，大概率是 autoloading 没覆盖src/DataFixtures/，检查composer.json的"autoload-dev"是否包含该路径
load() 里 persist 了但数据库没数据？漏了 flush()
$manager->persist($entity) 只是把对象加入 UnitOfWork，不调 $manager->flush() 就不会真正写入数据库 —— 而且完全静默，没有任何报错提示，看起来像“执行成功但没效果”。这是最常踩的坑。
正确写法示例：
public function load(ObjectManager $manager): void
{
$user = new User();
$user->setUsername('admin');
$manager->persist($user);
$manager->flush(); // ✅ 必须有这一行
}
- 每个 Fixture 类的
load()方法末尾都要显式flush()，别指望其他类帮你刷 - 批量插入超 1000 条时，建议每 100 条
flush()一次，并紧跟$manager->clear()防内存溢出 - 如果用了
--append模式，flush()依然必要，否则新增数据不会落地
Integrity constraint violation: 1452？依赖顺序没声明
错误信息类似 SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row，本质是子表记录先于父表插入，比如 PostFixtures 在 UserFixtures 之前执行，但 Post 外键指向的 User 还没创建。
Doctrine 默认按类名**字母序**加载 Fixture，不看文件时间、不认 001_ 前缀 —— 那些纯属自我安慰。
- 必须让依赖类实现
DependentFixtureInterface - 在子类中重写
getDependencies()，明确返回父类全限定名：return [UserFixtures::class]; - 确保被依赖的类（如
UserFixtures）也实现了DependentFixtureInterface，否则依赖关系无效
想直接跑 SQL 或注入服务？别硬套 ORMFixtureInterface
ORMFixtureInterface 强制你用实体 + persist()，但有些场景不适合：比如初始化字典表（几百条 INSERT）、需要密码编码（得用 security.encoder_factory）、或操作多个 EntityManager。
这时应改用更底层的接口：
- 要执行原生 SQL：
use Doctrine\Common\DataFixtures\FixtureInterface，然后通过$manager->getConnection()->executeStatement($sql)执行；注意 PostgreSQL 的多语句需拆分，不能一股脑prepare() - 要注入服务：把 Fixture 声明为服务，在
services.yaml中加bind或arguments，再让类构造函数接收（例如$encoderFactory），但注意它不实现 ORMFixtureInterface，不能用--em=xxx参数控制 EntityManager - 多 EntityManager 场景下，
doctrine:fixtures:load --em=default会失败，因为默认只扫描主 EM 的映射命名空间；必须确保对应 Fixture 类里的load()显式使用目标 EM 实例（如从$this->container->get('doctrine.orm.symblog_entity_manager')获取）
复杂点在于：一旦脱离 ORMFixtureInterface，你就得自己管理事务、flush、依赖解析和环境适配 —— 官方命令的便利性基本归零，但换来的是完全可控的执行逻辑。
