ThinkPHP 6 中应通过中间件在路由进入后、响应返回前用 Redis 原子 incr 统计 API 请求次数，配合日志钩子捕获错误请求，并每日定时落地 Redis 数据至 MySQL 进行聚合查询，确保统计口径一致且高性能。
ThinkPHP 6 中用中间件统计接口请求次数
直接在中间件里记录请求，比在每个控制器里写逻辑更可靠，也避免漏统计。关键不是“怎么存”，而是“什么时候存”——必须在请求进入路由之后、响应返回之前完成计数，否则会漏掉异常中断的请求。
创建中间件 App\Middleware\RequestCounter，在 handle() 方法中操作：
public function handle($request, \Closure $next)
{
// 只统计 API 路由，排除静态资源和后台页面
if (str_starts_with($request->url(), '/api/') === false) {
return $next($request);
}
$path = $request->path();
$method = $request->method();
// 使用 Redis 原子自增，避免并发写入丢失
$key = 'api:count:' . md5($method . ':' . $path);
$this->app->redis()->incr($key);
return $next($request);
}
- 务必用
md5()处理路径，防止含参数的 URL（如/api/user/123）被当作不同接口重复计数 - 不要用数据库直接
INSERT ... ON DUPLICATE KEY UPDATE，高并发下容易锁表或主键冲突 - 如果项目没开 Redis，改用
Cache::inc()，但需确认缓存驱动支持原子操作（File 驱动不支持）
后台查询接口调用次数的 SQL 和模型写法
Redis 里只有原始计数，后台要查“近7天各接口调用 Top10”，就得把 Redis 数据定期落地到 MySQL，并支持按时间维度聚合。不能每次查询都扫一遍 Redis key —— 没有时间戳，无法过滤。
推荐做法：每天凌晨用命令行任务把当天的 Redis 计数写入 api_request_log 表（含 date、method、path_md5、count 字段），后台只查这张表。
立即学习“PHP免费学习笔记（深入）”；
// 后台控制器中查询示例
$top10 = Db::name('api_request_log')
->where('date', '>=', date('Y-m-d', strtotime('-7 days')))
->group('method, path_md5')
->order('sum(count) desc')
->limit(10)
->select();
-
path_md5字段必须建联合索引：(date, method, path_md5)，否则WHERE + GROUP BY会全表扫描 - 别在后台实时从 Redis
KEYS api:count:*扫数据——生产环境 key 过万时会阻塞 Redis - 如果需要精确到小时的统计，
date字段得改成datetime，并按DATE_FORMAT(create_time, '%Y-%m-%d %H:00')分组
ThinkPHP 日志钩子补充记录失败请求
上面的中间件只记了“进来的请求”，但 404、500、验证失败这些也需要统计——它们同样反映接口健康度。TP6 的日志事件钩子比手动 try-catch 更轻量。
在 app/event.php 中监听 think\facade\Log::EVENT_LOG_WRITE，识别出错误日志里的接口路径：
use think\facade\Log;
Log::listen(function ($level, $message, $context) {
if ($level === 'error' && isset($context['url'])) {
$path = parse_url($context['url'], PHP_URL_PATH);
if (str_starts_with($path, '/api/')) {
// 写入单独的 error_count 表或 Redis error:count:xxx
Redis::incr('api:error:' . md5($path));
}
}
});
- 这个钩子不会影响正常响应流程，但要注意
$context结构依赖日志配置；若用了自定义日志处理器，可能没有url字段 - 不要在这里做 DB 写入，日志是高频操作，DB I/O 会拖慢整个日志系统
- 404 请求默认不触发该钩子（因为没走到日志写入阶段），需在全局异常处理里补一手
前端展示时注意时间范围与缓存穿透
后台管理页用 ECharts 展示趋势图，用户选“最近30天”，接口却直接拼 SQL 查30天×接口数——这是典型缓存穿透。Redis 里根本没有空结果缓存，每次都会打到 DB。
- 查询前先检查
cache:api:trend:2024-05-01-2024-05-30是否存在，不存在再查库并设 10 分钟过期 - 日期参数必须校验格式，防止 SQL 注入：
DateTime::createFromFormat('Y-m-d', $start)比strtotime()更安全 - 如果用户导出 CSV，别用
Db::select()全量拉取——加chunk(500, function ($list) { ... })流式写入
真实难点不在代码怎么写，而在于“统计口径是否一致”：中间件记的是所有进来的请求，日志钩子记的是抛异常的，而数据库落地任务又可能因服务器宕机漏跑一天。得在后台加个“数据完整性校验”入口，比对 Redis 当前值和 MySQL 累计值的差额。
