中间件后置操作日志应基于请求上下文（用户ID、路由、参数、IP等）记录，避免依赖响应内容；需过滤敏感字段、限制参数长度、异常兜底；禁止在after中执行耗时操作，宜前置查询或异步处理；操作日志须独立建表并索引，失败操作同样需记录。
中间件里怎么拿到用户操作数据
ThinkPHP 的中间件后置执行时，$request 和 $response 都还在作用域内，但控制器已返回结果，$response->getContent() 可能为空（尤其用了 JSON 输出或重定向）。真正能稳定取到的，是请求上下文：用户 ID、路由、方法、参数、IP、时间戳这些。
关键点在于别等控制器吐出结果再记日志——你根本不需要它。操作日志的核心是「谁在什么时候干了什么」，不是「返回了什么」。
-
$request->session()->get('user_id')或$request->userId（如果已绑定到 Request） -
$request->url()+$request->method()拼出操作路径 -
$request->param()取参数，但要过滤敏感字段（如 password、token），建议白名单：array_intersect_key($params, array_flip(['id', 'name', 'status'])) -
$request->ip()尽量用这个，别信X-Forwarded-For（可能伪造）
写入数据库前必须处理的三件事
直接把 $request->param() 序列化进日志表，不出三天就炸：超长文本截断、JSON 字符串转义混乱、SQL 插入失败。不是不能存，是得先「收口」。
- 参数长度限制：用
mb_substr(json_encode($params), 0, 2000)截断，避免TEXT字段溢出 - 敏感字段清除：显式 unset
password、old_password、token、auth_key等键名，别依赖前端不传 - 异常兜底：写入用
try...catch包住，捕获PDOException，失败至少记到本地文件（error_log("log write failed: ...")），别让日志逻辑拖垮主流程
为什么不能在 after 里查数据库或调远程服务
ThinkPHP 中间件的 after 方法是同步阻塞执行的，如果在里面做耗时操作（比如查用户昵称、调鉴权接口、发 MQ），会拖慢所有请求的响应时间，且无法并发控制。
立即学习“PHP免费学习笔记（深入）”；
真实场景中，一个后台列表页批量操作可能触发 20 条日志写入，如果每条都查一次 User::find()，就是 20 次 DB 查询 —— 这不是日志，是雪崩引信。
- 用户信息（昵称、角色）应在中间件前置时查好，存在
$request->withAttr('operator_name', ...)里，后置直接取 - 绝对不要在
after里 new Model 或调Db::table()，改用预定义的轻量日志模型（只含insert()，无事件、无验证、无关联） - 高并发下考虑异步：把日志数组推到
think-queue或 Redis List，由独立 worker 消费，中间件只负责「丢进去」
Log::write() 不等于操作日志，别混用
ThinkPHP 自带的 Log::write() 是调试/错误日志，格式固定、输出到文件、不带结构化字段。它没法按「用户ID」或「操作类型」查，也不能做统计报表。
操作日志必须走独立数据表（比如 sys_operation_log），字段至少包含：user_id、username、route、method、params、ip、status（1 成功 / 0 失败）、created_at。
- 状态判断看
$response->getCode()是否为 200，但注意：403、404 也可能是合法业务操作，建议结合控制器返回的['code' => 0]这类约定来标 success - 别用
Log::init()配置去“接管”操作日志，那是给自己埋兼容性雷——TP 升级可能砍掉旧日志驱动接口 - 表加索引：至少给
user_id和created_at加联合索引，否则查某人上周操作会扫全表
最常被跳过的其实是「失败日志也要记」：权限拒绝、参数校验不通过、DB 写入冲突……这些恰恰是最该审计的操作，但很多人只在 try 成功分支里写日志。
