ThinkPHP需自行安全封装操作日志接口，禁止直接暴露原始日志；应建结构化数据库表、严格权限校验、脱敏字段、限定查询条件与分页，并优化索引及分页方式。
ThinkPHP 没有开箱即用的「操作日志接口」，所有对外暴露的日志查询能力都必须自行封装——直接把 runtime/log 文件路径或数据库日志表通过 API 返回是危险且不可维护的。
为什么不能直接提供 /api/log/list 这类接口
操作日志不是调试日志，它含敏感上下文（如 user_id、操作参数、IP），未经脱敏和权限校验就暴露成接口，等于把审计凭据公开。常见错误现象包括：
- 前端调用
/api/log/list?uid=123就返回该用户全部操作记录，绕过 RBAC 权限检查 - 接口返回原始
input字段，含密码、token、身份证号等未脱敏内容 - 未限制分页大小，一次请求拉取 10 万条日志，拖垮数据库和带宽
如何安全封装操作日志查询接口
核心原则：只暴露「审计所需字段」，不暴露「原始日志载体」。推荐用数据库表存操作日志（非文件），再封装接口：
- 建表时预留
user_id、action、method、ip、created_at、status（成功/失败）、summary（脱敏后的简要描述）字段，避免存完整input - 接口路由如
/admin/log/operation，仅允许admin角色访问，后端用Auth::check('log:read')校验权限 - 查询参数强制限定：
page、limit=20（最大不超过 100）、start_time/end_time（跨度不超过 7 天）、user_id（仅支持查当前用户或下属，不支持任意 uid 查询） - 返回字段剔除所有敏感项，例如把
input替换为summary: "编辑用户ID=123，状态设为启用"
如何对接已有的中间件日志写入逻辑
如果你已用 OperationLogMiddleware 把日志写进数据库，那接口只需复用同一张表，但要注意三点：
立即学习“PHP免费学习笔记（深入）”；
- 中间件写入时用了
Log::info()记文件？赶紧停掉——接口查的是数据库，文件日志无法结构化查询 - 中间件中记录的
input是原始$request->param()，接口层必须做字段白名单过滤（如只留id、status），再 JSON 编码进summary - 别在接口里重新查一遍
$request->param()去“还原操作”，而是信任中间件当时存的summary字段——时间差会导致数据不一致
容易被忽略的权限与性能细节
最常翻车的地方不在代码，而在边界控制：
- 管理员能查全量日志，但必须加
WHERE created_at > DATE_SUB(NOW(), INTERVAL 30 DAY)，否则查一年前的数据会锁表 - 导出 Excel 功能不能走同一个接口，得单独开
/admin/log/export并走队列异步生成，防止超时 - 如果日志表超过 500 万行，
created_at字段必须有索引，且分页不能用LIMIT 10000,20，改用游标分页（WHERE created_at < '2026-04-20 10:00:00' ORDER BY created_at DESC LIMIT 20）
