弹幕三分钟才到，我在风控上绕了一圈

「我发了条弹幕，模型一分多钟没理我。」

这是我的原话。当时的第一判断是模型慢——毕竟前面刚花了不少时间在压语音合成的耗时上。但去翻日志，发现弹幕压根还没被捕获到：

18:18:35  捕获事件 type=danmaku
18:21:03  捕获事件 type=danmaku
18:24:20  捕获事件 type=danmaku

三条记录之间隔着将近三分钟。也就是说，我发完弹幕之后，插件要等到下一个轮询周期才会看见它。不是不回，是还不知道有这条弹幕。

报错一直在刷

日志里有一行反复出现：

[B站直播] 弹幕接口疑似被 B站风控，5s 后重试:
弹幕服务器信息获取失败: code=-352 message=-352

而且退避时间是递增的：5s → 30s → 60s → 120s → 240s。插件是在正常降级——主通道失败就退避重试，退避的间隙靠"历史弹幕轮询"兜底。问题是退避涨到 240 秒之后，兜底轮询也被拖到了一分多钟一次。

先怀疑 Cookie，但 Cookie 是好的

-352 是 B 站的风控码，最常见的解释是登录态有问题。我用配置里的 SESSDATA 打了两个接口验证，第一个是用户信息：

Cookie 有效性: isLogin = True | 用户名: <我的用户名>

登录态完全正常。 第二个是报错里那个接口，也就是 getDanmuInfo：

弹幕接口: -352 -352

同一个 Cookie，nav 能过、getDanmuInfo 被拒。所以不是登录态失效，是这个特定接口对当前环境有额外校验——大概率是 Cookie 里缺了 buvid3 之类的设备标识字段，我只填了 SESSDATA。

插件的说明里写着答案

我准备去改插件源码的时候，顺手把配置项的说明读完了：

bilibili_web_backend   可选：history / laplace / blivedm / builtin
hint: 推荐 builtin。builtin 为 B站直连；
      history 只使用历史弹幕轮询，不请求 websocket 弹幕服务器信息，
      适合 getDanmuInfo -352 风控时使用

作者早就把这种情况写进去了。 builtin 会去请求那个被风控的接口，失败后按递增退避重试——把时间全浪费在撞墙上。history 模式干脆不请求它，直接用历史弹幕轮询。

改成 history，重启，日志变成：

[B站直播] 已启动 history-only 弹幕监听: interval=3.0s

三分钟变成三秒。

剩下的

轮询毕竟不是推送，延迟从"三分钟"降到"三秒"已经够用，但理论上还是有一个轮询周期的滞后。想彻底回到实时推送，得把 Cookie 补全——从浏览器 F12 里复制整条 Cookie 字符串（不只是 SESSDATA 那一项），把 buvid3、bili_jct 这些一起带上，让 getDanmuInfo 能过。这个我还没试。

这次真正浪费时间的不是排查，是没把配置说明读完。那份 hint 写得很直白，连"适合 getDanmuInfo -352 风控时使用"这种话都给了，我在前面查 Cookie、查接口、翻源码，绕了一大圈。

插件作者踩过的坑，通常已经写在配置说明里了。以后遇到奇怪的默认行为，先把说明念一遍。