事件本身仅为信号，查询逻辑须在监听器handle()中实现，通过use模型或Db类安全查询，注意类型对齐、NULL处理、避免耗时操作及异常中断。
ThinkPHP 事件里不能直接查数据库，得靠事件监听器里调用模型或 Db 类 —— 事件本身只是触发信号，不带查询能力。
事件监听器里怎么安全查数据
事件（比如 user_login）被触发后，实际查询逻辑必须写在监听器类的 handle() 方法里。别在事件类里写 find() 或 select()，它没继承模型，也没 DB 实例。
- 监听器需手动引入模型：用
use app\model\User;再调User::where(...)->find() - 若不想耦合模型，可用
think\Db：比如Db::name('user')->where('id', $uid)->find() - 注意事务上下文：事件可能在事务中触发，但监听器默认不在同一事务内，
Db::transaction()不会自动透传，要显式处理 - 避免在监听器里做耗时查询，尤其
select()带join或未加索引字段，容易拖慢主流程
where 条件在事件监听里容易错哪几种
监听器里写的 where() 和控制器里一样脆弱，但更容易忽略类型对齐和 NULL 处理。
-
where('status', '1')→ 数据库字段是TINYINT时，PDO 模式下条件会被丢弃，查不到结果也不报错 -
where('email', $_POST['email'])→ 没过滤空值，$_POST['email']是空字符串时生成WHERE email = ''，不是你想要的“有邮箱”的用户 -
where('updated_at', null)→ 生成= NULL，永远为 false，得改用whereNull('updated_at') - 模糊查询漏
%：where('name', 'like', $keyword)如果$keyword没包%，就是等值匹配，不是搜索
关联查询 or 多表 join 能不能放事件里
能放，但得评估必要性。事件监听器不是查报表的地方，别在 user_login 里顺手查出用户所有订单 + 商品 + 物流信息。
立即学习“PHP免费学习笔记（深入）”；
- 简单关联推荐用
with()：比如User::with('profile')->find($uid)，比手动两查更可控 - 多表
join要显式指定别名：用alias('u')->join('order o', 'u.id = o.user_id')，否则字段冲突会导致getData()取不到值 - 别在监听器里调用
paginate()—— 它依赖 HTTP 请求上下文，事件里没有Request实例，会抛异常 - 如果真要分页或复杂聚合，建议把数据查好后发到队列异步处理，别卡主线程
最常被忽略的一点：事件监听器的返回值不影响主流程，但里面的异常会冒泡中断整个事件派发链。哪怕只是 find() 返回 null 后没判空就直接取 ->name，也会导致后续监听器全跳过。
