真正能保障运维安全的后台操作日志必须在中间件中结构化捕获用户、动作、参数、结果等关键上下文并独立落库；需全局注册、精准过滤免日志接口、字段语义化拆解、敏感操作留痕原数据、写入隔离且高可用。
真正能保障运维安全的后台操作日志，不是零散写在控制器里的 Log::write()，而是在请求生命周期最稳的位置——中间件里，结构化捕获用户、动作、参数、结果等关键上下文，并独立落库可查。
必须用中间件，而不是控制器或行为钩子
控制器里手动记日志容易漏掉异常分支、参数不全、登录态已失效；行为钩子（如 login_success）只适合离散事件，覆盖不了所有后台接口。中间件运行在「路由解析完成、控制器执行之前」，能稳定拿到 $request->action()、$request->controller()、Auth::id() 等真实上下文，是唯一可全局覆盖的入口。
- 注册位置：在 app/middleware.php 中全局启用，不依赖路由分组
- 拦截时机：使用 handle() 获取请求前上下文，after() 补成功日志；异常需在全局异常处理器中补失败记录
- 避开免日志接口：用 in_array($request->action(), ['login', 'logout', 'captcha']) 过滤，别靠 URL 字符串匹配
日志字段要拆解，不能存大文本
把整条请求参数 JSON 塞进一个 content TEXT 字段，等于没审计——查不了、筛不动、索引失效。必须按语义拆关键字段，让日志真正可检索、可聚合。
- admin_id：非空整型，来自 Auth::getUserID()，未登录填 NULL，禁用 session('admin_id') 直读
- action：格式为 module/controller/action，用 $request->rule()->getModule() + getController() + action() 拼接，不解析 URL
- params：用 array_filter() 显式剔除 ['password', 'token', 'old_password'] 后再 json_encode，MySQL 5.7+ 建议设为 JSON 类型
- created_at 和 admin_id 必须建联合索引，高频查询场景下没索引的日志表撑不过一周
敏感操作要额外留痕，不能只靠日志字段
删除用户、修改权限、开关配置这类高风险动作，光记“谁干了什么”不够，还要锁定“改了什么”和“原本是什么”。
- 加 is_sensitive = 1 字段，方便后续审计时快速筛选，避免翻全量日志
- 对 DELETE/UPDATE 操作，在写日志前主动查一次原数据，存入 before_data（JSON 格式），例如用户邮箱、角色 ID、状态值
- 别用 Db::table()->delete() 后补日志——它绕过模型，也绕过你的中间件。高危接口建议强制走带审计逻辑的 Service 层
写入方式要隔离，不能拖慢主流程
日志写入失败不能影响业务响应，更不能卷入主事务导致回滚失败。
- 禁用 MyISAM 表存日志，必须用 InnoDB；写入用独立数据库连接：Db::connect('log_db')->name('admin_log')->insert()
- 不要用 think-queue 异步入库——延迟导致“操作成功但日志缺失”，审计链路断裂
- 测试时务必模拟日志库不可写（如权限拒绝、网络中断），确认主业务仍能正常返回，这是上线前必过的一关
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
