tp6的log反复记录同一错误是因为默认不聚合重复错误，每次log::error()调用均独立写入；可通过自定义日志处理器或loghelper封装实现基于消息、文件、行号指纹的去重，并保留首次时间戳和trace_id等关键上下文。
为什么 TP6 的 think\facade\Log 会反复记录同一错误？
不是日志配置错了，而是 TP6 默认不聚合重复错误——只要 Log::error() 被调用一次，就写一行。比如某个接口因数据库连接失败，在 1 秒内被高频重试 20 次，日志里就会塞进 20 条几乎一模一样的 [error] PDOException: SQLSTATE[HY000] [2002] Connection refused。这既掩盖真实问题，又拖慢磁盘 I/O，还让 ELK 或 Sentry 告警爆炸。
TP6 日志处理器不支持原生去重，但可接管写入前的过滤逻辑
TP6 的日志底层走的是 think\log\driver\File（或其他驱动），它在写入前会触发 handle() 方法。我们不能改框架源码，但可以在自定义日志处理器中插入判断：对最近 60 秒内相同错误消息 + 相同文件行号的记录，只保留第一条，后续转为计数标记。
实操建议：
- 继承
think\log\driver\File，重写save()方法，在调用父类写入前检查是否已存在近似重复 - 用
md5($record['message'] . $record['file'] . $record['line'])生成指纹，缓存在Runtime/log_dedup/下的临时文件（避免 Redis 依赖） - 指纹文件按小时分片，例如
dedup_20240520_14.php，内容为['f8a9b...'=> ['count'=>5, 'first_time'=>1716213602]] - 当计数 ≥ 3 时，跳过写入，改用
Log::info("[DEDUP] {$msg} (x{$count})")合并提示
Log::error() 调用位置分散？统一收口到封装函数更可控
直接在业务代码里满地打 Log::error()，等于放弃聚合入口。不如建一个 app\common\helper\LogHelper，把所有错误上报走这里：
function log_error(string $msg, array $context = []): void
{
$trace = debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 2);
$caller = $trace[1] ?? $trace[0];
$fingerprint = md5($msg . ($caller['file'] ?? '') . ($caller['line'] ?? ''));
// 这里接入上面的 dedup 判断逻辑
if (should_dedup($fingerprint)) {
Log::info("[DEDUP] {$msg} (x" . get_dedup_count($fingerprint) . ")");
return;
}
Log::error($msg, $context);
}
这样连第三方 SDK 抛出的异常，也能通过 set_exception_handler() 统一兜底进 log_error()，不会漏掉。
聚合后日志时间戳和 trace_id 仍要保留，否则排查失焦
去重不是抹除上下文。即使合并记录，也要确保关键诊断信息不丢：
- 首次报错的
$record['time']必须记下来，合并日志里显示为"First seen at 2024-05-20 14:32:01" - 如果项目启用了 trace_id（如通过中间件注入到
Log::getChannel()->withContext()），聚合时需取首个 trace_id，而不是丢弃 - 避免把不同请求的错误强行合并——必须校验
$context['trace_id']是否为空，空则允许聚合；非空则按 trace_id 分组，防止 A 用户的 500 和 B 用户的 500 被当成同一错误
真正难的从来不是“怎么去掉重复”，而是“去掉哪些重复、留下哪些上下文”。指纹只看 message+file+line 是最简方案，但线上遇到跨微服务调用或异步队列场景，就得把 context 里的 service、queue 字段也纳入哈希——否则看似去重了，实际把两类故障混成了一团。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
