接口日志问题核心在于“写得不准、不全、不可查”，需针对性配置日志通道、独立路径、结构化上下文及数据库存储。
接口日志记录不全，核心问题不是“没写”，而是“写得不准、不全、不可查”。ThinkPHP 默认日志机制面向页面请求设计，API 场景下若不做针对性调整，很容易漏掉关键上下文、混入页面日志、或因配置时机/权限/级别问题导致静默丢弃。
确保日志通道真正启用且匹配 API 环境
生产环境（APP_DEBUG = false）下，ThinkPHP 默认跳过日志写入。光有 runtime/log 目录存在，不代表日志在工作。
- 检查 config/log.php 中，default 通道是否指向有效驱动（如 'file'），且 record 显式设为 true
- level 必须包含你期望记录的级别，例如 ['error', 'info', 'sql']；空数组或未配置 level 会导致全部过滤
- 确认 APP_DEBUG = false 时，log.trace 若需堆栈（如 error 日志带文件行号），必须在 config/log.php 中设为 true —— 它默认关闭，且只对 error/notice 生效
- 避免用 LOG_LEVEL 环境变量动态控制，除非你在 public/index.php 加载框架前已定义，且格式为逗号分隔字符串（如 error,sql）
为接口请求单独初始化日志路径
默认日志统一写入 runtime/log/ 下按日期分目录的文件，API 和页面日志混在一起，排查困难，还容易因并发写入冲突或单文件过大导致丢失。
- 在 API 入口中间件（如 app\common\middleware\ApiLog.php）中，每次请求都调用 Log::init()，指定独立路径：
Log::init(['type'=>'File', 'path'=>RUNTIME_PATH.'api_log/', 'single'=>true, 'level'=>['error','info']]） - 确保 RUNTIME_PATH . 'api_log/' 目录存在且 PHP 进程用户（如 www-data）有写权限；目录不存在时日志会静默失败，无报错提示
- 不要复用全局日志配置，避免和后台管理、前台页面日志互相干扰
补全关键上下文，让日志真正可追溯
单纯记录 “info: 用户登录” 没用。真实排障需要知道谁、从哪、什么时候、做了什么、参数是什么（脱敏后）。
- 在中间件中获取并结构化记录：admin_id 或 user_id（通过 Auth::getUserID() 或安全封装的登录态校验，别直接读 session）、IP（$request->ip()）、URL + method、action 名（$request->action()）、非敏感参数（用 array_filter 过滤 password/token 等键）
- 为每条日志附加唯一 request_id（如生成 UUID），便于串联 Nginx、PHP、数据库等多层日志
- 对敏感操作（如删除、权限变更）打标 is_sensitive=1，后续审计可快速筛选
- 避免用 Log::record() 后就不管——它只是入队，请求结束才刷盘；若需立即落盘（如关键操作完成即记），调用 Log::save()，但勿滥用
考虑结构化存储替代纯文本文件
文本日志查起来费劲：想查某 IP 的所有操作？某管理员的最近 10 条修改？全文本搜索慢、难索引、易撑爆磁盘。
- 建专用日志表，拆字段：admin_id、ip、module、controller、action、params（JSON 或 text）、is_sensitive、created_at
- 给 created_at 和 admin_id 加联合索引，高频查询才扛得住
- 实现自定义日志驱动（继承 think\log\driver\File 或重写 save 方法），把 Log::record() 的内容插入数据库，而非写文件
- 保留文件日志作兜底，数据库写失败时 fallback 到本地 api_log/ 下，保证不丢
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
