方法论与洞察

「重启才好」是缓存了时效凭证的指纹

首次记录：2026-08-02 来源：LiveLink 断线重连 —— 用户描述「点停止再点开始也没用，只能重启软件」，这句话本身就指向了根因状态：⚠️ 首次

一句话

用户说「只能重启才好」时，优先怀疑：进程内缓存了某个带时效的凭证，而且那份缓存没有失效路径。

把三种「重来」摆在一起看，它们的区别正好把嫌疑范围压到很小：

所以：重连不好、停止再开始也不好、唯独重启好 ⇒ 坏掉的东西活在「比业务对象更长命、但比进程更短命」的那一层 —— 典型就是模块级缓存。

再叠加「一开始能用、用着用着就不行了」这个时间特征 ⇒ 缓存的是带时效的东西： token / session / 签名 / 预签名 URL。

第三方库把弹幕服务器的握手 token 存在模块级 Map 里，永不失效、无对外清除入口。 token 过期后，无论重连多少次、还是「停止→重新开始」重建对象，拿到的都是同一份失效 token —— 只有重启进程才会重新去取。

实测证据：同一房间连续两次 startListen，打印出的 token 完全相同。

听到「只能重启才好」→ 先去找模块级 / 全局单例上的缓存，而不是先读业务逻辑。
确认缓存里存的东西有没有时效。有时效 + 无失效路径 = 根因。
修的时候，失效判断不要用时间（猜不准过期点），要用权威信号 —— 凭证被服务端拒绝的那一刻，就是显式作废的时机。
但也别走向另一个极端「每次都回源」：LiveLink 实测发现未登录状态下高频取 token 会被平台风控（-352）。最终采用「短 TTL 复用 + 失败时显式作废」双轨。
排查时优先构造能直接打印缓存内容的最小脚本（本次就是连两次、比对 token），比读代码推断可靠得多。

「重启才好」也可能是资源泄漏（句柄 / 内存 / 端口占用）—— 那类通常伴随越用越慢 或报错换了一种，而凭证类是从某一刻起稳定地失败。
无时效的静态缓存（图标、字体表、配置表）缓存越久越好，不适用本条。

类型/协作工具链