symfony测试中模拟服务需分单元与功能测试：单元测试直接注入mock对象验证逻辑；功能测试用static::$container->set()替换容器内服务实例，确保请求生命周期中生效。
在 Symfony 测试中模拟服务，核心目标是**隔离被测代码、避免副作用、精准验证行为**。不是所有场景都适合同一种方式——单元测试用 Mock 对象注入，功能测试则需绕过容器限制，让模拟服务真正生效。关键不在“怎么写 mock”，而在于“mock 怎么进容器、何时起作用”。
单元测试：直接注入 Mock 服务
适用于验证业务逻辑本身是否正确调用依赖服务，不涉及 HTTP 请求或容器启动。
- 用
$this->createMock(YourService::class)创建模拟对象 - 在构造或 setter 中显式传入该 Mock（如
new UserService($mockDispatcher)） - 对 Mock 设置期望行为，例如：
$mock->expects($this->once())->method('sendEmail')->with($this->stringContains('welcome')); - 无需修改服务配置，也不依赖容器 —— 纯对象协作测试
功能测试：替换容器中的服务实例
当你通过 $client->request() 触发完整请求生命周期，控制器/服务从容器中自动获取依赖时，必须让容器返回你的 Mock。
- 使用
static::$container->set('service.id', $mock)替换服务（仅限继承KernelTestCase或WebTestCase的测试类） - 注意：每次请求前都需重新设置，因为客户端会在请求间重建内核
- 若遇 “服务私有不可 set” 错误，不要改
services.yaml公开它 ——static::$container是测试专用容器，天然支持私有服务覆盖 - 服务 ID 优先用类名（如
App\Service\PaymentGateway::class），比字符串 ID 更安全
事件调度器专项模拟
事件派发逻辑容易漏测，推荐两种轻量可靠方式：
-
Mock EventDispatcherInterface：用
$this->createMock(EventDispatcherInterface::class)，断言dispatch()是否被调用、参数是否匹配事件类和名称 -
Prophecy 预言式模拟：更语义化，例如
$dispatcher->dispatch($event, 'order.created')->shouldBeCalled()，适合强调“应发生什么”而非“如何发生” - 避免在测试中启用真实监听器 —— 它们可能触发邮件、HTTP 调用等外部行为
避免踩坑的实用细节
很多失败源于对容器机制理解偏差：
- 别在
config/packages/test/services.yaml里用decorates或alias想“全局替换” —— 功能测试中它不生效，且易污染其他测试 - 不要试图在
services.yaml中设public: true再用$client->getContainer()->set()—— 这是旧版 Symfony 2/3 的做法，现代版本已不必要 - Mock 外部客户端（如 Guzzle、Redis）时，禁用原始构造函数 + 设置方法行为即可，不必模拟整个服务类
- 测试结束后无需手动清理容器 ——
KernelTestCase会自动重置
