Bug: 采集 TAGs 时疯狂报错（topic_svr/topic_history 接口已废弃，固定返回 code 65539）

[tianmaozuo]

描述Bug

Bug: 采集 TAGs 时疯狂报错（topic_svr/topic_history 接口已废弃，固定返回 code 65539）
中文正文 + 英文摘要见文末。Issue 标题建议：
【Bug】采集 TAGs 疯狂报错：topic_svr/topic_history 接口已失效（code 65539）

1. 概述
   配置 TAGs 后启动 lottery start，采集阶段会对每一个 tag 逐页（tag_scan_page 默认 3 页）发起请求，每页都返回空数据并触发异常，控制台被大量错误刷屏，表现为"疯狂报错"。
2. 环境
   版本：lottery 2.11.2（pkg 单文件二进制 lottery.exe）
   上游：shanmiteko/LotteryAutoScript
   系统：Windows 10/11
   配置相关项：TAGs: ['抽奖号的日常']、tag_scan_page: 3、LotteryOrder 含 1（TAGs）
3. 复现步骤
   在 my_config.js 配置 TAGs（非空），例如 TAGs: ['抽奖号的日常']
   确保 LotteryOrder 包含 1（TAGs 采集）
   运行 start.bat / lottery start
   观察启动后采集阶段的日志
4. 预期行为
   采集 TAGs 动态，返回该话题下的抽奖动态列表，无异常。
5. 实际行为
   每个 tag × 每页都报错。根因定位到的请求与响应如下：
   请求接口：https://api.vc.bilibili.com/topic_svr/v1/topic_svr/topic_history
   （代码常量 TOPIC_SVR_TOPIC_HISTORY，定义于 lib/net/api.bili.js；调用函数 getLotteryInfoByTag，位于 lib/core/monitor.js）
   接口当前固定返回：
   {"code": 65539, "data": {}}
   解析层在 data 为空 / 字段缺失时抛出异常，按 tag_scan_page 逐页记录 → 大量重复错误。
   典型错误日志（示意）：
   [ERROR] 采集 TAGs「抽奖号的日常」第 1 页失败: Cannot read properties of undefined (reading 'length')
   [ERROR] 采集 TAGs「抽奖号的日常」第 2 页失败: ...
   [ERROR] 采集 TAGs「抽奖号的日常」第 3 页失败: ...
6. 根因分析
   api.vc.bilibili.com/topic_svr/v1/topic_svr/topic_history 是 B站老话题接口，B站已将话题相关接口迁移到 gRPC，老接口已停用并固定返回 code: 65539 空数据（权威来源：bilibili-API-collect 社区 Issue #852，备注"分分钟爆金币"）。
   因此该问题属于上游接口失效，并非网络/限流/字段类型/空值处理等用户侧问题——但采集函数对 code !== 0 的情况缺少 warn + skip 兜底，叠加逐页重试逻辑，才放大成"疯狂报错"。其余数据源（UIDs 走 space/动态接口、Articles 走专栏接口、APIs 走 search/type）均为仍可用接口，不受影响。
7. 建议修复
   (A) 采集函数兼容已失效接口（推荐，最小改动）
   在 getLotteryInfoByTag 中对 code !== 0 做"仅 warn 一次并跳过该页"，不再逐页抛错；并加指数退避/重试：
   async function getLotteryInfoByTag(tag, page = 1) {
   const url = TOPIC_SVR_TOPIC_HISTORY + '?topic_name=' + encodeURIComponent(tag) + '&page=' + page;
   try {
   const res = await biliClient.get(url);
   if (!res || res.code !== 0) {
   console.warn([TAG] ${tag} 接口返回 code:${res && res.code}（接口可能已失效），跳过该页);
   return []; // 不再抛错，避免疯狂刷屏
   }
   const list = (res.data && res.data.cards) || [];
   return list.map(mapTopicCardToLotteryInfo); // 按现有字段映射
   } catch (e) {
   console.warn([TAG] ${tag} 请求异常，退避后重试: ${e.message});
   await delay(backoff);
   return page === 1 ? [] : getLotteryInfoByTag(tag, page);
   }
   }
   (B) 迁移到仍可用接口（更彻底）
   将 TAGs 采集改为调用仍可用的搜索接口，按话题名取动态：
   const url = 'https://api.bilibili.com/x/web-interface/search/type'

• '?search_type=2&keyword=' + encodeURIComponent(tag) + '&page=' + page;
  // 响应 res.data.result 为动态列表，再 map 到 LotteryInfo
  无论采用 (A) 或 (B)，都建议对"接口返回非 0"只 warn + skip，从机制上避免单点接口故障被放大成海量报错。

8. 临时规避方案（用户侧）
   在 my_config.js 中将 TAGs 置空 TAGs: []。无论 LotteryOrder 是否包含 1，空数组都不会向该死接口发起请求，报错立即停止；UIDs / Articles / APIs 等其他数据源正常采集。
9. 参考
   bilibili-API-collect Issue #852：topic_svr 老话题接口已停用，迁 gRPC。
   已确认仓库现有 issues（官方抽奖识别错误 #445 官方抽奖识别错误、推荐邮箱smtp/pop3服务 #53 smtp）与本问题无关，无重复上报。
   English Summary
   Title: 【Bug】TAGs collection spams errors — topic_svr/topic_history endpoint is dead (returns code 65539)
   When TAGs is configured, lottery start calls getLotteryInfoByTag (lib/core/monitor.js) which hits the deprecated https://api.vc.bilibili.com/topic_svr/v1/topic_svr/topic_history endpoint (constant TOPIC_SVR_TOPIC_HISTORY in lib/net/api.bili.js). Bilibili has migrated topic APIs to gRPC, so this endpoint now always returns {"code": 65539, "data": {}}. The collector lacks a code !== 0 → warn + skip guard and retries per tag_scan_page, turning every page into a thrown exception — hence the "crazy errors". Other sources (UIDs/Articles/APIs) are unaffected.
   Fix suggestion: add a code !== 0 guard (warn + skip, no throw) and/or migrate TAGs collection to the still-working x/web-interface/search/type endpoint. Workaround: set TAGs: [] to stop the calls.

重现Bug

1

预期行为

1

截图

No response

运行日志

1

操作系统

Win11

NodeJs版本

No response

脚本版本

最新

其他

No response