如何利用ThinkPHP构建关键业务行为操作日志审计与跟踪记录系统？

本文共计1089个文字，预计阅读时间需要5分钟。

使用直接框架默认的日志写法记录用户操作，很容易遇到以下三个硬伤：

实操建议：

立即学习“PHP免费学习笔记（深入）”；

• 不要复用 think\facade\Log，新建专用日志驱动，比如继承 think\log\driver\File 并重写 save() 方法，强制写入 runtime/audit/ 目录
• 每条日志必须包含：user_id（从 auth 或 session 取）、ip（request()->ip()）、action（如 "order_create"）、data（关键字段脱敏后 JSON，如 {"order_no":"ORD2024...","amount":99.9}）
• 避免记录原始 $_POST 或 $request->param() —— 体积大、含敏感字段、难以回溯意图；只提取明确业务语义的字段

用中间件统一拦截关键控制器方法

手动在每个控制器里写日志极易遗漏或不一致。中间件是唯一能保证“所有订单创建、资金划转、权限变更”必留痕的入口。

实操建议：

立即学习“PHP免费学习笔记（深入）”；

• 定义中间件 AuditMiddleware，在 handle() 中判断当前路由是否匹配预设规则，例如：Str::is('api/v1/order/*', $request->url()) || Str::is('admin/user/assign*', $request->url())
• 使用 $request->rule()->getRuleName() 获取路由标识，比解析 URL 更稳定；对 POST/PUT 请求，在 after() 钩子中写日志（确保操作已执行成功）
• 注意异常场景：若控制器抛出异常，after() 不触发 —— 需在 AppException 全局异常处理器中补写失败日志，标记 status = "failed" 并附带 exception->getMessage()

数据库表设计要预留扩展性，别只存 text 字段

审计日志查得少、写得多，但一旦要查“张三昨天修改过哪些商品价格”，靠 content TEXT 模糊搜索会拖垮数据库。

实操建议：

立即学习“PHP免费学习笔记（深入）”；

• 基础字段必须有：user_id、action（索引）、ip、created_at、status（"success"/"failed"）、trace_id（关联同一请求链路）
• 业务字段单独建 JSON 字段（如 payload JSON），MySQL 5.7+ 或 PostgreSQL 可直接用 -> 操作符查询，例如：WHERE payload->>'$.order_no' = 'ORD2024...'
• 避免把日志当消息队列用：不要在审计表里加 is_handled、handler 等字段 —— 审计日志只负责“记”，后续分析走独立服务或定时任务

敏感操作必须二次确认 + 日志落库后不可删改

日志写到文件或数据库只是第一步。真正起审计作用的前提是：它不能被业务代码覆盖、删除，也不能被误操作清空。

实操建议：

立即学习“PHP免费学习笔记（深入）”；

• 数据库层加 BEFORE DELETE 触发器，或应用层重写 AuditLogModel::destroy() 抛出异常；线上环境禁止开放 audit_log 表的 DELETE 权限
• 对高危动作（如删除管理员、清空库存），在控制器里增加 if ($this->request->post('confirm') !== 'I_CONFIRM_DELETE') 校验，并把该 confirm 字段也记入日志
• 文件存储方案需额外处理：启用 Linux 的 chattr +a（仅追加），或定期同步到只读 NAS；否则运维一个 rm -rf 就让所有审计失效

最常被忽略的一点：日志里的 user_id 必须来自认证后的 session 或 token 解析结果，绝不能取自前端传参。哪怕只是个 GET /user/delete?id=123，也要先查出该 ID 对应的真实操作人再记日志 —— 否则“越权操作”本身就成了盲区。