在 Laravel 8 测试中验证事件需先调用 Event::fake() 拦截事件，再执行业务逻辑，最后用 Event::assertDispatched() 断言；不可在 setUp() 中提前 fake，可指定伪造事件数组，支持 assertNotDispatched 和 assertDispatchedTimes。
在 Laravel 8 测试中验证事件是否被正确分发，必须绕过框架默认禁用模型事件的机制，否则 creating、saving 等事件根本不会注册，断言必然失败——这不是代码问题，而是测试环境的隔离策略所致。
启用事件并伪造监听器执行
第一步：在测试方法开头调用 Event::fake()，它会拦截所有事件分发，阻止监听器实际运行，同时保留事件调度记录供断言使用。
第二步：执行触发事件的业务逻辑，例如创建模型、调用服务或手动 dispatch 事件。这一步必须发生在 Event::fake() 之后，否则事件不会被记录。
第三步：使用 Event::assertDispatched() 断言事件类已被调度。若需校验事件携带的数据，传入闭包回调，对事件实例属性做精确匹配——比如检查订单 ID 是否与预期一致。
注意：【不能在 setUp() 中提前调用 Event::fake()】，因为 Laravel 8+ 的 TestCase 默认执行 withoutEvents()，若再提前 fake，会导致事件完全不可见，断言永远失败。
只伪造特定事件（避免干扰其他逻辑）
方法一：传入事件类数组，仅屏蔽指定事件，其余事件照常执行。
Event::fake([OrderShipped::class, PaymentProcessed::class]);
方法二：适合需要保留邮件通知、日志写入等非目标事件行为的场景，防止测试因意外事件中断。
方法三：伪造后仍可对未被伪造的事件做完整断言，比如 Mail::assertSent(WelcomeEmail::class) 不受影响。
断言事件未被触发
直接调用 Event::assertNotDispatched(UserRegistered::class) 即可。
这一步操作起来很简单，但前提是确保该事件确实不该在此路径中发生——比如用户注册失败时，不应分发 UserRegistered 事件。
若断言失败，说明业务逻辑存在漏判分支，或事件被意外触发，需回溯事件分发点。
验证事件触发次数
① 使用 Event::assertDispatchedTimes(OrderShipped::class, 2) 断言某事件被分发恰好两次。
② 若业务逻辑中含循环创建多个订单，且每个订单都应触发一次 OrderShipped，此断言能精准捕获少发或多发问题。
③ 注意：该方法不支持闭包校验，如需同时验证次数和数据，请拆分为两个断言——先用 assertDispatched 带回调校验数据，再用 assertDispatchedTimes 校验频次。
