必须显式控制广播数据序列化，禁用直接广播模型；在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 配置完成，但字段级过滤得在事件数据生成时做。
使用场景：管理员看到完整订单信息，客服只能看到订单号和状态，用户只能看到自己的收货地址摘要。
- 广播事件类中不要依赖全局 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()）的判断都会失效。
