[提问] 不知道为什么live.LiveDanmaku在disconnet之后会自动重连

[LondonClass]

Python 版本： 3.13.3

模块版本： 17.4.1

运行环境： Windows

import bilibili_api
import asyncio

async def test_danmaku():
    print("初始化配置...")
    room_id = 23899847
    credential_dict = {}
    credential = bilibili_api.Credential(sessdata=credential_dict['SESSDATA'], bili_jct=credential_dict['bili_jct'], buvid3=credential_dict['buvid3'], dedeuserid=credential_dict['DedeUserID'], ac_time_value=credential_dict['ac_time_value'])
    live_danmaku = bilibili_api.live.LiveDanmaku(room_display_id=room_id, credential=credential, max_retry=864000)
    
    print("创建连接任务...")
    task_live = asyncio.create_task(live_danmaku.connect())
    
    print("等待3秒...")
    await asyncio.sleep(3)
    
    print("尝试断开连接...")
    await live_danmaku.disconnect()
    
    print("等待2秒...")
    await asyncio.sleep(2)
    
    print(f"任务是否完成: {task_live.done()}")
    
    if not task_live.done():
        print("任务仍然在运行，尝试取消...")
        task_live.cancel()
        try:
            await task_live
        except asyncio.CancelledError:
            print("任务已被取消")
    
    print("测试完成")

if __name__ == "__main__":
    asyncio.run(test_danmaku())

结果是：
“””
初始化配置...
创建连接任务...
等待3秒...
[23899847][2026-02-14 13:41:17,515][INFO] 准备连接直播间 23899847
[23899847][2026-02-14 13:41:17,925][INFO] 正在尝试连接主机： wss://zj-cn-live-comet.chat.bilibili.com:2245/sub
[23899847][2026-02-14 13:41:18,050][INFO] 连接服务器并认证成功
尝试断开连接...
[23899847][2026-02-14 13:41:20,612][INFO] 连接正在关闭
[23899847][2026-02-14 13:41:20,613][INFO] 连接已关闭
等待2秒...
[23899847][2026-02-14 13:41:20,614][ERROR] 出现错误
[23899847][2026-02-14 13:41:20,614][WARNING] 非正常关闭连接
[23899847][2026-02-14 13:41:20,614][INFO] 正在尝试连接主机： wss://zj-cn-live-comet.chat.bilibili.com:2245/sub
[23899847][2026-02-14 13:41:20,745][INFO] 连接服务器并认证成功
任务是否完成: False
任务仍然在运行，尝试取消...
任务已被取消
测试完成
“””

看上去使用disconnet结束后好像会认为是非正常关闭连接然后自动重连

[LondonClass]

稍微魔改了一下，就能正常结束了：

另外LiveDanmaku.__main的这部分运行起来特别卡，可以优化一下性能吗？

[LondonClass]

这个第294行会阻塞主线程0.5秒。稍微改了一下

[Alkaid-C]

我这里试了一下无法复现。你具体用的哪个网络请求库？

这里出现了[23899847][2026-02-14 13:41:20,614][WARNING] 非正常关闭连接，说明你应该已经是执行到这里了：

bilibili-api/bilibili_api/live.py

Lines 1542 to 1549 in 0147ab6

	# 正常断开情况下跳出循环
	if self.__status != self.STATUS_CLOSED or self.err_reason:
	# 非用户手动调用关闭，触发重连
	self.logger.warning(
	"非正常关闭连接" if not self.err_reason else self.err_reason
	)
	else:
	break

self.error_reason为空（否则应该打印具体的error_reason），且self.__status不为DISCONNECTED...并且你的魔改也暗示了是self.__status不为DISCONNECTED导致的问题

那么看起来应该是这段出现了未知错误

bilibili-api/bilibili_api/live.py

Lines 1446 to 1452 in 0147ab6

	self.logger.info("连接正在关闭")
	# 取消所有任务
	while len(self.__tasks) > 0:
	self.__tasks.pop().cancel()
	self.__status = self.STATUS_CLOSED

，导致没有跑到

bilibili-api/bilibili_api/live.py

Line 1452 in 0147ab6

self.__status = self.STATUS_CLOSED

但这样的话连接已关闭的log是哪里发出来的？
另一个有这个log的地方是这里

bilibili-api/bilibili_api/live.py

Lines 1537 to 1540 in 0147ab6

	elif flag == BiliWsMsgType.CLOSED:
	self.logger.info("连接已关闭")
	self.__status = self.STATUS_CLOSED
	break

但它也会立即把status设为STATUS_CLOSED啊？

嗨呀，无法复现，如果你能提供更多信息就好了

(顺便，这玩意儿早该用状态机模型重构了 #945 ）

[LondonClass]

我这里试了一下无法复现。你具体用的哪个网络请求库？

应该是curl_cffi

但这样的话连接已关闭的log是哪里发出来的？

测试之后发现在1455行

bilibili-api/bilibili_api/live.py

Line 1455 in 0147ab6

self.logger.info("连接已关闭")

这么说disconnect()是跑完了，但__main()没跑完

检查以后发现错误的位置在1526行。

bilibili-api/bilibili_api/live.py

Lines 1525 to 1530 in 0147ab6

	try:
	data, flag = await self.__client.ws_recv(self.__ws)
	except Exception as e:
	self.__status = self.STATUS_ERROR
	self.logger.error("出现错误")
	break

打印出来是这样的：

[23899847][2026-02-18 12:16:41,879][ERROR] 出现错误Failed to WS_RECV, curl: (43) [WS] connection not found. See https://curl.se/libcurl/c/libcurl-errors.html first for more details.
Traceback (most recent call last):
  File "C:\Users\10415\AppData\Local\Programs\Python\Python313\Lib\site-packages\bilibili_api\live.py", line 1526, in __main
    data, flag = await self.__client.ws_recv(self.__ws)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\10415\AppData\Local\Programs\Python\Python313\Lib\site-packages\bilibili_api\clients\CurlCFFIClient.py", line 298, in ws_recv
    raise e
  File "C:\Users\10415\AppData\Local\Programs\Python\Python313\Lib\site-packages\bilibili_api\clients\CurlCFFIClient.py", line 282, in ws_recv
    chunk, frame = await loop.run_in_executor(None, ws.curl.ws_recv)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\10415\AppData\Local\Programs\Python\Python313\Lib\concurrent\futures\thread.py", line 59, in run
    result = self.fn(*self.args, **self.kwargs)
  File "C:\Users\10415\AppData\Local\Programs\Python\Python313\Lib\site-packages\curl_cffi\curl.py", line 476, in ws_recv
    self._check_error(ret, "WS_RECV")
    ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^
  File "C:\Users\10415\AppData\Local\Programs\Python\Python313\Lib\site-packages\curl_cffi\curl.py", line 187, in _check_error
    raise error
curl_cffi.curl.CurlError: Failed to WS_RECV, curl: (43) [WS] connection not found. See https://curl.se/libcurl/c/libcurl-errors.html first for more details.

[Nemo2011]

如果用 curl_cffi 的 ws 话建议修改一下 ws_recv 的代码，如下。

# clients/CurlCFFIClient.py

...

class CurlCFFIClient(BiliAPIClient):
    """
    curl_cffi 模块请求客户端
    """

    ...

    async def ws_recv(self, cnt: int) -> tuple[bytes, BiliWsMsgType]:
        ws = self.__ws[cnt]
        try:
            msg, flags = await ws.recv()
        except curl_cffi.CurlError as e:
            if e.code == curl_cffi.CurlECode.GOT_NOTHING:
                return (b"", BiliWsMsgType.CLOSED)
            else:
                raise e
        if not msg:
            msg = b""
        if flags & curl_cffi.CurlWsFlag.CLOSE:
            return (b"", BiliWsMsgType.CLOSE)
        if flags & curl_cffi.CurlWsFlag.TEXT:
            return (msg, BiliWsMsgType.TEXT)
        if flags & curl_cffi.CurlWsFlag.PING:
            return (msg, BiliWsMsgType.PING)
        return (msg, BiliWsMsgType.BINARY)

...

[GEYUANwuqi]

自动重连+1，同样用的curl_cffi，然而aiohttp没有这个问题，分析了一下是因为这样

# clients/CurlCFFIClient.py
    async def ws_close(self, cnt: int) -> None:
        if self.__ws_need_close[cnt] or self.__ws_is_closed[cnt]:
            return
        ws = self.__ws[cnt]
        self.__ws_need_close[cnt] = True
        request_log.dispatch(
            "WS_CLOSE",
            "关闭 WebSocket 请求",
            {"id": cnt},
        )
        ws.terminate()  # It's better to terminate than close.   ---> 罪魁祸首，使用ws.terminate() 会抛出错误
        self.__ws_is_closed[cnt] = True

使用traceback输出错误堆栈后，会发现触发了curl_cffi的WebSocketClosed

Traceback (most recent call last):
  File "D:\Miniconda\envs\bili_api\Lib\site-packages\bilibili_api\live.py", line 1119, in __main
    data, flag = await self.__client.ws_recv(self.__ws)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  ...
  File "D:\Miniconda\envs\bili_api\Lib\site-packages\curl_cffi\requests\websockets.py", line 609, in recv_fragment
    raise WebSocketClosed("WebSocket is closed")
curl_cffi.requests.websockets.WebSocketClosed: WebSocket is closed

然而在这段代码中为了适配请求库的抽象，并没有对curl_cffi抛出的错误进一步进行处理，而是宽泛的进行了Exception，从而导致了不正常的重启

# live.LiveDanmaku.__main
                while True:
                    try:
                        data, flag = await self.__client.ws_recv(self.__ws)
                    except Exception as e:
                        # if self.__status == self.STATUS_CLOSED:  # ---> 修复方案
                        #     break
                        self.__status = self.STATUS_ERROR
                        self.logger.error("出现错误")
                        # import traceback
                        # traceback.print_exc()  # ---> 打印错误堆栈，可复现WebSocketClosed
                        break

至于为什么aiohttp没有出现问题，是因为在aiohttp的关闭逻辑中，正确的向下游传递了关闭信息

# clients/AioHTTPClient.py
    async def ws_close(self, cnt: int) -> None:
        request_log.dispatch(
            "WS_CLOSE",
            "关闭 WebSocket 请求",
            {"id": cnt},
        )
        return await self.__wss[cnt].close() # ---> 正常关闭，触发LiveDanmaku.__main的关闭逻辑

修复也比较简单，为了保证请求库的抽象，可以在错误处理中增加进一步的检查，以应对curl_cffi的抛出

# live.LiveDanmaku.__main
                while True:
                    try:
                        data, flag = await self.__client.ws_recv(self.__ws)
                    except Exception as e:
                        if self.__status == self.STATUS_CLOSED:  # ---> 当已经关闭时，不重新设置状态
                            break  # ---> 跳出去触发__main的关闭逻辑
                        self.__status = self.STATUS_ERROR
                        self.logger.error("出现错误")
                        break

碎碎念: 能不能把__main逻辑改成非阻塞啊，现在这个逻辑写并发有点麻烦

[GEYUANwuqi]

纠正一下，我后面又觉得这个错误应该在 clients/CurlCFFIClient.py 里捕捉然后正常处理的，不应该改 live.LiveDanmaku.__main 源码，不然感觉会留下隐患导致其他适配库不能正常处理