ISSUE-0085：HTTP 列 tooltip 误导 — 把"批量复用"说成"日志被淘汰"¶

现象（用户截图 v0.10.121）¶

用户全新账号 — 43 商家 / 42 已采，远不够 5000 条 page-log buffer 上限。但 HTTP 列 hover tooltip 显示：

已采过此网站；详细日志已被环形 buffer 淘汰（保留最近 5000 条）

用户："这提示是不是有问题？" — 准确质疑。

根因 — v0.10.120 ISSUE-0083 修复时只看到一种可能¶

row.scrape_status === 2 但 pageLogMap.get(url) 缺失，实际有 3 种原因：

原因	何时发生	v0.10.120 tooltip
① 5000 条环形淘汰	老数据被新数据挤出 buffer	✅ 对
② batchDedupeByUrl 复用	连锁店共享 URL → v0.10.114 优化路径，update status=2 但不写 page-log	❌ 错
③ scraper-executor 查重复用	line 152-178 已采过的 sourceRow 复用，也不写 page-log	❌ 错

batchDedupeByUrl 的代码（engine-manager.ts:215-235）：

await updateByQuery('MapTaskData', { id: { in: ids } }, {
  emails: src.emails, ..., scrape_status: 2, sync: 0
});
// ↑ 没有 appendPageLog

用户截图：43 商家、连锁店共享 URL 多 → batchDedupeByUrl 跑出大量"复用行" → tooltip 全都说"日志被淘汰" → 用户被误导。

这是 fix-regression（修了一半）¶

v0.10.117 → 0.10.120 我犯了： - v0.10.117：改外层 overflow:'hidden' 防嵌套滚动 → 引入 ISSUE-0081 分页器被裁 - v0.10.120：修分页器、加 HTTP 列空兜底 tooltip → 假定一种原因，引入 ISSUE-0085

根本失误：修 UI 兜底文案前没列举所有可能的真实根因。

修复（v0.10.122）¶

if (row.scrape_status === 2) {
  const hasContact = (row.emails?.length || 0) > 0 || !!row.phone;
  const hint = hasContact
    ? '可能是同网址的其他商家先采过，本行通过「批量复用」获得了数据'
    : '可能是：批量复用、缓存命中、或较早采集已被日志淘汰';
  return (
    <Tooltip title={<Box>{...} 已采过（无详细日志）{hint}</Box>}>
      <Chip label="✓" />
    </Tooltip>
  );
}

不再假定原因
用 hasContact 启发式提示最可能场景
"可能是 / 或" 措辞避免再次撒谎

长期可选¶

让 batchDedupeByUrl 也写一条 page-log "mstage:reused-from-pool"，UI 就能精确显示。但代价：page-log 增长快（同 URL 复用 N 次 → N 条 log）。先不做。

教训¶

UI 兜底文案要诚实不假定：3 种可能就说 3 种，不要为了简洁撒谎
修代码前先 grep 同一现象的所有触发路径：v0.10.120 没 grep scrape_status: 2 看是谁写的
fix-regression 是隐性技术债：上次修出新坑，要计入"沉淀负债"
把这条规则加到 ui-change-pre-check：「兜底分支文案要列举所有触发原因，不能假定」

验证¶

装 v0.10.122 后：hover 已采但无日志的行： - 有 emails/phone → "可能是同网址的其他商家先采过..." - 无 contact → "可能是：批量复用、缓存命中、或较早采集已被日志淘汰" - 不再撒谎说"buffer 淘汰"