事件本身不做权限检查，因ThinkPHP的Event是纯通知机制，不拦截请求、不终止流程、无用户上下文；真正有效的权限拦截点只有中间件和控制器_initialize()方法。
事件本身不做权限检查——ThinkPHP 的 event 是纯通知机制，不拦截请求、不终止流程、也不自带用户上下文。真要做权限控制，得靠中间件或钩子配合手动校验，而不是指望 Event::trigger() 自动拦人。
为什么不能在 event 里做权限拦截
ThinkPHP 的事件系统（think\facade\Event）本质是发布-订阅模式，它只负责广播信号，不参与 HTTP 请求生命周期。你触发 user.deleted 或 order.paid，监听器执行完就结束，既不会影响当前响应，也无法阻止控制器继续运行。
常见误用场景：
- 在登录成功后触发
login.success事件，然后指望某个监听器“拦住未授权用户”——做不到，事件没返回值，更无中断能力 - 把权限判断逻辑塞进
UserDeletedListener，以为能阻止删除操作——实际删除早已完成，监听器只是事后收尸 - 试图在
app\common\event.php里写if (!Auth::check()) die('no')——语法错，且事件文件只注册监听器，不执行逻辑
哪些地方能真正做权限拦截
只有进入 HTTP 请求处理链路的环节才能中断执行。ThinkPHP 中真正有效的权限拦截点只有两个：
立即学习“PHP免费学习笔记（深入）”；
-
middleware：在app/middleware.php或类中间件的handle()方法中，调用$auth->can()后直接return redirect('/403')或return json(['code' => 403]) -
controller 初始化方法：如_initialize()，但必须确保它在认证中间件之后执行（否则$this->request->user()为空），且仅适合粗粒度控制（如整个模块登录态）
注意：behavior（行为钩子）也不能拦截——它和 event 一样是事后通知，module_end 钩子触发时，响应已生成，再 throw 异常也晚了。
event + middleware 怎么配合做审计类权限动作
如果你需要“某操作被允许执行后，再检查是否该记录日志/发通知/更新统计”，这才是 event 的正确打开方式：
- 权限检查由中间件完成（比如
CheckPermission拦下无权访问的/admin/user/delete） - 放行后，控制器执行删除逻辑，成功后显式触发
Event::trigger('user.deleted', $userId) - 监听器
UserDeleteLogger只负责写数据库日志，不查权限、不抛异常、不改状态 - 若需行级权限审计（如“谁删了谁的文章”），监听器从
$request->param('id')或传入参数取上下文，而非重新查 session 或 auth
这种分工下，权限控制干净，事件轻量，两者不耦合。
最容易被忽略的是执行时机：中间件顺序决定你能拿到什么数据；event 触发位置决定你能做什么事。别让监听器承担本该由中间件干的活，也别在事件里写 redirect 或 abort——那不是它的职责。
