必须显式控制广播数据序列化，禁用直接广播模型；在broadcastWith()中按接收者角色动态脱敏，显式白名单字段，禁止依赖请求上下文。

模型事件触发后如何安全广播私有字段

直接在 dispatch 或 broadcast 里传原始模型，等于把数据库字段全暴露给前端。Laravel 的 BroadcastEvent 不会自动脱敏，得自己控制序列化输出。

常见错误现象：前端收到 {"id":1,"email":"admin@example.com","password_hash":"$2y$10$..."} 这类数据；或者用 toArray() 暴露了本该隐藏的字段。

• 永远不要直接广播模型实例，改用显式构造数组：['id' => $user->id, 'name' => $user->name]
• 如果必须复用模型结构，重写模型的 toArray() 方法，在其中剔除敏感字段（如 password_hash、remember_token）
• 对不同角色使用不同脱敏规则时，不要在模型层硬编码逻辑，把脱敏逻辑提到广播事件类里，按当前广播上下文动态判断

Laravel 广播私有频道如何按接收者角色做字段过滤

私有频道（private- 前缀）只解决“能不能听”，不解决“听到什么”。频道鉴权通过 BroadcastServiceProvider 的 channels 配置完成，但字段级过滤得在事件数据生成时做。

使用场景：管理员看到完整订单信息，客服只能看到订单号和状态，用户只能看到自己的收货地址摘要。

Laravel Cloud

Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。

下载

• 广播事件类中不要依赖全局 auth 用户，而是通过 $this->user 显式传入当前接收者（比如在 toBroadcast 里传参）
• 用 Auth::user() 判断角色是错的——广播是服务端异步发的，此时请求上下文已丢失
• 推荐做法：在触发广播前，用 Notification::send($receivers, new OrderUpdated($order, $receiver))，让每个接收者拿到专属数据

为什么用 ShouldBroadcastNow 仍会泄露敏感字段

ShouldBroadcastNow 只跳过队列，不改变序列化行为。很多人以为“不走队列就更可控”，结果反而因为没经过队列中间件或日志拦截，脱敏逻辑被绕过。

性能影响：同步广播会让 HTTP 请求阻塞，但字段泄露是逻辑问题，不是性能问题。

• 脱敏逻辑必须放在事件类的 broadcastWith() 方法里，这是唯一可靠的序列化入口
• 别在控制器里先 toArray() 再传给事件——这会让脱敏逻辑分散，难维护
• 如果用了 toJson() 手动序列化，记得检查是否调用了模型的 hidden 或 casts，它们对 broadcastWith() 无效

广播事件里访问模型关系导致 N+1 和权限越界

在 broadcastWith() 里写 $this->order->customer->email 很常见，但这会触发额外查询，且可能跨权限边界（比如客服不该看到客户邮箱）。

容易踩的坑：关系加载没做权限校验，或用 loadMissing() 加载了整张关联表。

• 所有关系字段必须显式白名单，禁止用 with() 无差别预加载
• 需要关联数据时，用 select() 限定字段，例如 $this->order->customer()->select('id', 'name')->first()
• 如果关联模型也有脱敏规则，把它封装成独立方法（如 toBroadcastArrayFor($role)），别在事件里拼接逻辑

事情说清了就结束。最常被忽略的是：广播事件的序列化时机早于请求生命周期结束，所有依赖请求上下文（如 request()->user()、session()）的判断都会失效。