应在中间件中统一捕获操作日志，因仅中间件能稳定覆盖请求全生命周期；需在handle()末尾记录，过滤敏感参数，确保字段含module、controller、action、object_id、rule_name、client_ip等，并同步写入核心操作日志。
如何在ThinkPHP中间件里统一捕获操作日志
操作日志必须在请求生命周期早期介入，否则容易漏掉权限校验失败、路由未匹配等关键节点。中间件是唯一能稳定覆盖所有HTTP请求入口的位置，控制器或模型层记录会遗漏前置异常。
实操建议：
- 新建
app/middleware/OperationLogMiddleware.php，在handle()方法末尾写入日志，而非开头——确保能拿到最终响应状态和可能抛出的异常 - 用
$request->url(true)获取完整请求路径，避免因路由重写导致日志路径失真 - 不要直接读取
$request->param()记录全部参数，敏感字段（如密码、token）需白名单过滤，否则审计日志本身成风险点 - 若项目启用了多语言或区域中间件，确保日志中间件注册顺序靠后，否则
$request->lang()等上下文可能为空
为什么不能只靠Auth类的钩子记录权限操作
ThinkPHP的 Auth 类（或新版 think-auth）只管“是否允许”，不关心“谁在什么时间、用什么参数、操作了哪个资源”。它的钩子（如 onAuthCheck）触发时机早于控制器执行，拿不到业务数据ID、操作类型（新增/删除）、甚至用户真实IP（可能被代理头干扰）。
常见错误现象：
- 日志里只有
user_id=123, rule=article/edit，但无法追溯到具体编辑的是哪篇文章（article_id缺失） - 权限拒绝时日志为空——因为
Auth拒绝后直接中断流程，钩子没机会执行后续逻辑 - 使用
Auth::check()手动鉴权的场景（如API内部分支判断），钩子完全不触发
正确做法：权限校验后，在控制器动作内补全业务上下文，再交由日志服务统一落库。
数据库设计要预留扩展字段，别只存“操作描述”
初期只建 admin_log(content, user_id, create_time) 看似够用，但很快会卡在审计回溯环节：查不到操作对象ID、分不清是前端按钮点击还是定时任务触发、无法关联到RBAC的权限规则名。
必须包含的字段：
-
module和controller：用于归类模块级操作频次（如“系统设置模块日均修改37次”） -
action：对应方法名，不是URL路径，避免路由变动导致统计断层 -
object_id：被操作的主键值，整型，允许为0（如登录、退出无具体对象） -
rule_name：存储实际匹配的权限规则字符串（如user/delete），不是菜单ID——菜单可改名，规则名才是权限语义锚点 -
client_ip和user_agent：不用解析，原样存，留待后期做设备指纹或异常登录识别
异步写日志时要注意事务一致性
用 queue 或 Swoole\Coroutine 异步写日志看似提升性能，但会破坏“操作成功 ⇔ 日志必存”的强约束。例如用户提交订单成功，但日志队列崩了，审计链就断了。
折中方案：
- 核心操作（删用户、改权限、资金转账）必须同步写日志，哪怕慢20ms也要保证原子性
- 非关键操作（列表搜索、页面访问）可用
Log::channel('async')->info()走文件+轮询导入，避免数据库连接竞争 - 若坚持用消息队列，日志消息体里必须带
request_id，且消费端要检查该请求是否已在数据库存在同request_id的成功记录，防止重复写入 - 注意
Db::transaction()内不能调用异步日志，PDO连接在事务提交前会被复用，协程调度可能引发连接错乱
最常被忽略的一点：日志表的 create_time 必须用数据库 NOW()，而不是PHP的 time()。服务器时钟漂移、跨机房部署时，时间戳不准会让审计时间线错乱，连“谁先删了管理员再禁用账号”都理不清。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
