thinkphp 6 审计日志需独立存储、结构化、可溯源：新建专用日志驱动写入 runtime/audit/，含 user_id、ip、action、脱敏 data；用 auditmiddleware 统一拦截关键路由，after() 写成功日志，异常处理器补失败日志；数据库建基础字段+json payload，禁删改，user_id 必须来自认证态。
ThinkPHP 6 的 Log::write() 不适合业务审计日志
直接用框架默认日志写法记录用户操作，很快会遇到三个硬伤：日志混在 runtime/log/ 下难检索、无用户 ID 和请求上下文、无法按业务类型分类归档。审计日志必须独立存储、结构化、可关联溯源。
实操建议：
- 不要复用
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()—— 体积大、含敏感字段、难以回溯意图；只提取明确业务语义的字段
用中间件统一拦截关键控制器方法
手动在每个控制器里写日志极易遗漏或不一致。中间件是唯一能保证“所有订单创建、资金划转、权限变更”必留痕的入口。
实操建议：
- 定义中间件
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 模糊搜索会拖垮数据库。
实操建议：
- 基础字段必须有：
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等字段 —— 审计日志只负责“记”，后续分析走独立服务或定时任务
敏感操作必须二次确认 + 日志落库后不可删改
日志写到文件或数据库只是第一步。真正起审计作用的前提是：它不能被业务代码覆盖、删除，也不能被误操作清空。
实操建议：
- 数据库层加
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 对应的真实操作人再记日志 —— 否则“越权操作”本身就成了盲区。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
