DoctrineFixturesBundle 适合初始化数据库的静态快照，如开发环境预置管理员、CMS默认栏目；Foundry 更适合按需生成带状态语义的测试数据，支持链式调用与关联构造。
直接用 Zenstruck\Foundry，别写 Fixture 类——除非你明确需要手动控制事务边界、依赖顺序或复用到非测试场景。
DoctrineFixturesBundle 适合什么场景？
它适合初始化数据库的「静态快照」：比如开发环境预置管理员账号、CMS 的默认栏目、演示用的固定商品分类。但它的 load() 方法是一次性全量 flush，不支持按需生成、无法链式调用、没有状态抽象，写起来容易变成“硬编码数据表”。
- 常见错误现象：
ReferenceNotFoundException—— 没实现DependentFixtureInterface就在PostFixture里调$this->getReference('user-1') - 参数差异：
load(ObjectManager $manager)只能拿到原始 ORM 管理器，不能自动注入 Faker、不能复用工厂逻辑 - 性能影响：每次
php bin/console doctrine:fixtures:load都会 truncate 表并重插，CI 中跑得慢；若没加--append，还会清空已有测试数据
Foundry 怎么替代 Fixture 写法？
把实体变成可配置的工厂类，用 PHP 方法代替硬编码字段。比如 UserFactory::new()->active()->withPosts(3)->create() 一行就搞定带关联的用户+文章。
- 使用场景：单元测试中构造单个对象、功能测试前准备上下文、集成测试中模拟边界数据（如过期订单、未验证邮箱）
- 实操建议：安装后运行
php bin/console make:factory User，它会生成src/Factory/UserFactory.php，然后直接在测试里调用UserFactory::createOne() - 容易踩的坑：
create()是持久化到 DB 的，createMany(5)会插入 5 条；如果只想构造内存对象（不入库），得用make()或makeOne() - 兼容性注意：Symfony 6.4+ 默认启用
doctrine.dbal.url的 SQLite 内存模式，但 Foundry 要求 DB 支持事务回滚，SQLite:memory:在某些驱动下不支持嵌套事务，建议改用sqlite:///%kernel.project_dir%/var/test.db
WebTestCase 里怎么安全加载测试数据？
别在 setUp() 里反复调 doctrine:fixtures:load——那会清空整个库。用 Foundry 的 database_reset_strategy 配置 + refresh 模式，或者手动在每个 test 方法开头 UserFactory::createOne()。
- 常见错误现象：测试之间数据污染，比如上一个 test 创建了 email=‘a@test.com’ 的用户，下一个 test 也用这个邮箱注册，触发唯一约束异常
- 实操建议：在
phpunit.xml.dist里配SYMFONY_DEPRECATIONS_HELPER=weak，并在tests/bootstrap.php中调用DatabaseResetter::setStrategy(DatabaseResetter::STRATEGY_REFRESH) - 为什么这样做：Refresh 策略会在每个 test 前执行
TRUNCATE（不是 DROP），保留表结构和外键，比recreate快 3–5 倍；而none策略适合你完全靠createOne()按需生成的场景
真正难的不是生成数据，而是让每条数据的语义清晰可读——比如 OrderFactory::asPaid()->withItems(2)->create() 比手写 $order->setStatus('paid') 更接近业务语言。别为了“看起来像生产数据”而堆砌 Faker 字段，先确保状态标识准确，再补内容细节。
