应显式指定广播字段而非调用 $model->toArray()，因 hidden/casts 不生效于事件监听器；推荐使用 only() 或 toBroadcastArray() 方法，并在 broadcastWith() 中严格脱敏，避免泄露 password、token 等敏感字段。
模型事件里直接广播 $model->toArray() 会泄露敏感字段
Laravel 的模型事件（比如 created、updated）常配合广播（如 Pusher、Ably）实时通知前端。但很多人直接把整个模型转成数组发出去：$model->toArray()，结果 password、api_token、remember_token 全跟着飞走了——不是漏在日志里，是真·广播给所有人听。
根本原因：Laravel 默认不干预模型转数组的字段，hidden 或 casts 属性只影响 API 响应（即 toJson() 或资源类），而事件监听器里手动调用 toArray() 绕过了这层保护。
- 别在事件监听器里写
event(new UserCreated($user->toArray())) - 改用
$user->only(['id', 'name', 'email', 'updated_at'])显式指定要广播的字段 - 如果字段多且固定，建议在模型里加个方法，比如
toBroadcastArray()，内部调用only()并做简单处理（如格式化时间） - 注意：不要依赖
toArray()+$hidden，它对事件广播无效
用 EloquentEvent + 自定义广播类时，shouldBroadcastUsing() 里必须脱敏
如果你用的是 Laravel 的广播事件（继承 ShouldBroadcast），并在 shouldBroadcastUsing() 中返回自定义广播驱动（比如 PusherBroadcaster 实例），那数据组装就完全由你控制——这时候最容易忘掉脱敏。
常见错误：在 broadcastWith() 方法里直接返回 $this->user->toArray()，或者没意识到 $this->user 是 Eloquent 模型实例，toArray() 不自动过滤 hidden 字段。
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
-
broadcastWith()返回的数组就是最终发出去的数据，必须手工筛一遍 - 推荐写法：
return $this->user->only(['id', 'name', 'avatar_url', 'is_online']) - 如果需要动态逻辑（比如管理员能看到更多字段），在
broadcaseWith()里加判断，但别把权限校验逻辑塞进广播类——它不该负责这个 - 避免在
broadcastWith()里调用关系加载（如$this->user->posts），容易 N+1 和泄露关联数据
用 ApiResource 做广播数据？不推荐，性能和语义都不对
有人想“复用” API 资源类（UserResource）来统一输出结构，于是写 (new UserResource($user))->resolve() 当广播数据。这看似干净，实则埋雷。
问题在于：ApiResource 是为 HTTP 响应设计的，它可能触发懒加载、调用 toArray() 以外的访问器（如 getAvatarUrlAttribute()），还可能因请求上下文（如当前用户权限）改变输出——而广播事件没有 request 对象，request() 辅助函数会报错或返回空。
- 资源类里的
when()、whenLoaded()在广播中行为不可控 - 资源类默认会包含所有已加载的关系，哪怕你没在
with()里显式声明 - 性能上：资源类做了大量不必要的转换（如日期格式化、包装 data 包裹），广播不需要这些
- 真正该复用的是模型上的方法，比如
toBroadcastArray()，它不依赖请求、无副作用、可测
测试广播数据是否脱敏，得在事件触发后抓原始 payload
光看代码觉得“我写了 only()”，不代表实际发出去的就是安全的。真实环境里，广播数据可能被中间件、驱动封装、甚至 Pusher 控制台调试工具二次处理，导致你以为脱敏了，其实没生效。
最靠谱的验证方式：在本地用 log 驱动，或用 tinker 手动触发事件，然后查 storage/logs/laravel.log 里广播事件的 payload；或者用 Laravel Echo Server + Chrome 控制台监听 pusher:subscription_succeeded 后的真实消息体。
- 别只测 API 接口返回，广播是另一条链路
- 检查日志时重点搜
"password":、"token":、"remember_token"这类关键词 - 如果用了队列异步广播，确保队列 worker 已启动，并在日志里看到
Broadcasting event行 - 生产环境别用
log驱动，但可以用pusher+ 开发者控制台实时看 raw message
only()，而是每次加新字段、改模型属性、引入新关系时，都得重新检查广播出口——没人会记得。 
