必须用 $this->getReference()，不能手动 new 实体或查数据库，因其是唯一能保证跨 Fixture 数据引用正确、避免外键冲突和重复插入的方式；它依赖先 addReference 再 getReference 的内存映射机制，需严格遵循执行顺序与依赖声明。
必须用 $this->getReference()，不能手动 new 实体或查数据库。这是唯一能保证跨 Fixture 数据引用正确、避免外键冲突和重复插入的方式。
为什么不能在 load() 里 new 实体或调用 Repository 查询
Fixture 执行时数据库事务尚未提交，所有 $manager->persist() 的对象还只是“托管状态”。此时：
- 手动
new User()并设 ID —— ID 是假的，没进 DB，其他 Fixture 拿不到 - 用
$this->container->get('doctrine')->getRepository(User::class)->findOneBy([])—— 查不到刚 persist 但未 flush 的数据，返回 null 或报错 - 依赖
ContainerAwareInterface调服务查库 —— 同样查不到未提交数据，且破坏 Fixture 的纯数据层职责
$this->getReference() 的使用前提和写法
它不是魔法，需要你先在某个 Fixture 类中显式 $this->addReference()，再在其他类中引用。典型流程：
- 在
UserFixtures::load()里：$user = new User(); $manager->persist($user); $this->addReference('user-superadmin', $user); - 在
PostFixtures::load()里：$user = $this->getReference('user-superadmin'); $post->setAuthor($user); - 引用 key（如
'user-superadmin'）必须全局唯一，建议带前缀防冲突 - 被引用的 Fixture 必须已执行（靠
getDependencies()保证顺序），否则getReference()抛ReferenceNotFound异常
常见错误：引用失效或报错 ReferenceNotFound
这不是代码写错了，而是加载顺序或注册时机出了问题：
- 忘了在提供方 Fixture 中调
$this->addReference()——getReference()永远找不到 - 两个 Fixture 都用了相同 key（比如都用
'admin'）—— 后注册的覆盖前一个，引用错乱 - 依赖声明不完整：A 引用 B，B 引用 C，但 A 的
getDependencies()只写了 B，没写 C —— C 可能还没执行，A 就去引用了 - 运行命令时加了
--group却漏掉了提供 reference 的 Fixture 所属组 —— 它根本没执行，reference 自然不存在
大批量数据下引用性能与内存注意点
每调一次 $this->addReference()，loader 就把实体对象存进内存 map；引用越多，内存占用越高。1000+ 条数据时容易 OOM：
- 避免给每条记录都加 reference（如
'user-1','user-2'…），改用逻辑分组（'users-admins','users-regulars'） - 如果只是要“任意一个用户”，就只 add 一两个 reference，别全加
- 不用
$this->getReference()的场景（如简单枚举值），直接 new + set 字段更轻量 - flush 前记得
$manager->clear()清托管实体 —— 但注意：clear 后getReference()返回的对象会变成 detached 状态，关联赋值可能失效，慎用
reference 机制本质是内存里的对象映射表，不是数据库查询。它的可靠性完全取决于你是否严格遵守“先 add，再 get；先依赖，后引用”这个链条。漏掉任意一环，就会在测试里跑出奇怪的空指针或约束失败，而且很难 debug。
