From 680f3e6a89526ba50b6305a2851cc0994a364827 Mon Sep 17 00:00:00 2001 From: youpaishidifu Date: Tue, 15 Sep 2026 15:47:15 +0800 Subject: [PATCH] =?UTF-8?q?fix:=20=E9=99=88=E6=97=A7=E6=97=B6=E9=97=B4?= =?UTF-8?q?=E6=88=B3=E6=B6=88=E6=81=AF=E7=9B=B4=E6=8E=A5=E6=8B=92=E7=BB=9D?= =?UTF-8?q?=EF=BC=8C=E4=B8=8D=E8=BF=9B=E5=85=A5DB=E6=9F=A5=E5=BA=93?= =?UTF-8?q?=E7=AC=AC=E4=BA=8C=E5=85=B3=20(Task=20#1713)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 根因：第二关基于DB记录时间判断（created_at），但DB记录是当前OCR抓取时 由 record_ocr_message() 创建的，无法反映消息的真实发送时间。 一条昨天17:26的消息在今天15:32被OCR抓取，DB记录时间为15:32， time_diff=0 ≤ 300 → 通关 → 旧消息被误处理。 修复： 1. 第一关失败后，如果消息时间戳明确超过1小时(freshness_score==-10.0)， 直接拒绝(score=-100.0)，不进入第二关的DB查库逻辑。 2. freshness_scores字典查找默认值从0.0改为-999.0（无时间戳）， 防止查字典失败时误以为有新鲜时间戳而放行旧消息。 3. 增加cleaned_item二次查找，应对content filter修改ts导致的key不匹配。 --- monitor.py | 26 ++++++++++++++++++++++---- 1 file changed, 22 insertions(+), 4 deletions(-) diff --git a/monitor.py b/monitor.py index 6f8423d..c7bf10f 100644 --- a/monitor.py +++ b/monitor.py @@ -11056,8 +11056,12 @@ class MessageMonitor: score = self._score_message_quality(cleaned_item) # ⭐ 时间戳新鲜度评分：使用预先计算的freshness_score # 从freshness_scores字典中获取当前消息的时间戳新鲜度分数 - freshness_score = freshness_scores.get(item, 0.0) - # ⭐ Task #1680: 调试日志 - 查看freshness_score查找 + # ⭐ Task #1713: 默认值从0.0改为-999.0（无时间戳），防止查字典失败时 + # 误以为有新鲜时间戳而放行旧消息。同时用cleaned_item做二次查找 + # （content filter可能修改了ts，导致原始key不匹配）。 + freshness_score = freshness_scores.get(item, -999.0) + if freshness_score == -999.0 and item != cleaned_item: + freshness_score = freshness_scores.get(cleaned_item, -999.0) _in_dict = item in freshness_scores logger.debug(f"[{platform}] freshness_score查找: item={item!r:.30}, score={freshness_score:.1f}, " f"在字典中={_in_dict}") @@ -11077,10 +11081,24 @@ class MessageMonitor: score = max(score + 5.0, 5.0) logger.info(f"[{platform}] 第一关通过：有新鲜时间戳(自身)，放行: {old_score:.1f}→{score:.1f}: {item[:50]}") else: - # 第一关未通过：没有新鲜时间戳，进入第二关 + # 第一关未通过：没有新鲜时间戳 + + # ⭐ Task #1713: 陈旧时间戳直接拒绝，不进入第二关 + # 根因：第二关基于DB记录时间判断（created_at），但DB记录是当前OCR抓取时 + # 由 record_ocr_message() 创建的，无法反映消息的真实发送时间。 + # 一条昨天17:26的消息在今天15:32被OCR抓取，DB记录时间为15:32， + # time_diff=0 ≤ 300 → 通关 → 旧消息被误处理。 + # 修复：如果消息自身有明确时间戳但已超时（freshness_score == -10.0）， + # 直接拒绝，不给第二关任何放行机会。 + if freshness_score == -10.0: + score = -100.0 + logger.info(f"[{platform}] 陈旧时间戳直接拒绝(freshness={freshness_score:.1f}): {item[:50]}") + self._last_new_msg_time[platform] = time.time() + continue + logger.debug(f"[{platform}] 第一关未通过：无新鲜时间戳(自身)，进入第二关: {item[:50]}") - # 第二关：查库判断 + # 第二关：查库判断（仅用于无时间戳的消息，freshness_score == -999.0） # ⭐ Task #1693: 修复旧消息"搭便车"问题 # 旧消息通过 get_latest_record_timestamp() 搭上新消息的新鲜DB记录， # 导致 time_diff≤300s → 通关 → 分数从15→20/18→23，盖过真正的新消息。