laravel 测试应优先使用框架内置 fake() 方法而非手动 mockery：event::fake()、bus::fake()、http::fake()、queue::fake() 更轻量稳定；手动 mock 仅用于特殊场景，且推荐 $this->mock() 而非原生 mockery。
直接说结论：Laravel 的「模拟」不是靠写一堆 Mockery::mock() 手动拼装，而是优先用框架内置的 fake() 方法——它更轻、更稳、更少出错。手动 mock 只在极少数需要控制返回值逻辑或测试私有方法时才必要。
用 Event::fake() 和 Bus::fake() 替代手写事件/任务 mock
很多人一看到“要 mock 事件”，就立刻去写 Event::shouldReceive() 或 \Mockery::mock()，结果发现断言失败、报错 Method ... does not exist，或者监听器根本没被拦截——因为 Laravel 门面的静态调用不走容器解析，shouldReceive() 在门面上基本无效。
-
Event::fake()会全局禁用所有事件分发，但保留assertDispatched()/assertNotDispatched()断言能力，且支持闭包条件过滤 -
Bus::fake()同理，能验证任务是否被 dispatch、参数是否匹配，还能用assertDispatchedAfterResponse()区分同步/响应后执行场景 - 别在
setUp()里反复调用fake()；每个测试方法开头调一次就够了，重复调会清空之前记录的 dispatch 历史 - 如果测试中混用了真实事件（比如你只 fake 部分事件），得显式传入类数组：
Event::fake([OrderShipped::class, PaymentProcessed::class])
用 Http::fake() 拦截外部请求，别让测试连真实 API
功能测试里调第三方 HTTP 接口，最常见错误是忘记 fake，导致测试随机失败（API 限流、网络抖动、返回结构变动）或泄露敏感凭证。而用 Http::fake() 不仅安全，还能精准控制响应内容和顺序。
- 伪造单个端点：
Http::fake(['https://api.pay.com/charge' => Http::response(['id' => 'ch_123'], 201)]) - 用通配符覆盖整个域名：
Http::fake(['https://api.*' => Http::response([])])，防止漏掉子路径 - 需要测重试或分页？用
Http::sequence()推送不同响应，第三次自动 404：Http::fake(['*' => Http::sequence()->push(...)->push(...)->pushStatus(404)]) - 务必加兜底规则：
Http::fake(['*' => function () { throw new Exception('Unexpected HTTP request'); }])，避免遗漏请求静默通过
用 Queue::fake() 验证队列路由，而不是等 worker 消费
测试多队列（如 invoices、notifications）时，很多人直接改 QUEUE_CONNECTION=sync 然后看日志，结果发现 onQueue() 设置没生效、任务全进了 default 队列——这是因为 sync 驱动默认忽略队列名，只管执行。
- 正确做法是
Queue::fake()+assertPushedOn('invoices', ProcessInvoice::class)，它只校验元数据，不执行任务 - 若需验证连接名（比如你配置了
redis_invoices和redis_notifications），得传数组参数：Queue::fake(['redis_invoices', 'redis_notifications'])，否则未 fake 的连接仍会真实推送 -
assertPushed()默认检查所有连接，加上第三个参数false才跳过连接名比对；真要校验连接，用闭包：Queue::assertPushed(ProcessInvoice::class, fn ($job) => $job->connectionName === 'redis_invoices') - 注意：fake 后调用
dispatchNow()不受拦截，它绕过队列系统直行——该测同步逻辑就别 fake，该测队列路由就别用dispatchNow()
手动 mock 服务类时，优先用 $this->mock() 而非 \Mockery::mock()
当你必须替换一个具体服务（比如 PaymentGateway），又不想污染容器绑定，$this->mock() 是最简路径。自己 new Mockery 对象再 bind 到容器，容易漏掉 $this->app->instance() 或类型提示不匹配。
-
$this->mock(PaymentGateway::class)->shouldReceive('charge')->andReturn(true);一行搞定，后续app(PaymentGateway::class)或构造注入都会拿到这个 mock - 不要在
setUp()里 mock 全局服务，除非所有测试都依赖它；否则单个测试内 mock 更清晰、无副作用 - mock 接口比 mock 具体类更安全，比如
PaymentGatewayContract，避免耦合实现细节 - 部分 mock（只 stub 个别方法）用
\Mockery::partialMock()，但注意 Eloquent 模型不能 partialMock，会破坏构造逻辑；此时改用工厂构造 + 关系 stub 更稳妥
真正容易被忽略的是：fake 和 mock 的作用域都是「当前测试方法」，跨方法不共享；而多个断言（比如 assertDispatched() 多次）必须在同一个测试方法里完成——拆成两个 test 方法，历史记录就清空了。
