第 13 章　升级与备份

程序会持续改进，这一章讲两件事：怎么把现在的版本换成新版本，怎么把数据备到另一处。 升级前先备份，换坏了随时回得去；平时定期备份，机器坏了数据还在。 两件都是按顺序做下来的事，跟着走就行。

代理接入配置

升级后，如用 NovaBot 会话接入管理后端，请将代理检查地址改为 /config/api/admin-session-check（有部署前缀时加上前缀），并保留后端自身的登录与角色检查； 其他实例无需调整。使用原有检查地址时，本次运行只记一条日志提醒，管理员打开网页控制台后， 各页顶部也会显示同样的提醒。改好代理配置并重启 NovaBot，且不再使用原有检查地址后，提醒不再出现。 原有 /config/api/session-check 继续用于所有有效角色的会话检查。 接入示例见代理服务使用控制台会话。

升级前先留好这几样

• 备份 application.yml 与 datasource.json，它们是你的全部配置
• 备份 cookies.json 与 cookies.key，它们等同于哔哩哔哩账号的完整控制权
• 旁边若还有 cookies.json.plain.bak，那是明文迁成加密时留下的明文原件，程序不读它：不用备、升级后也不用拷回，确认能正常登录后就把它删掉

登录凭据默认加密后仍写在 cookies.json 里，密钥在 cookies.key，没有另存一份密文文件， 所以这两个都要备。直播数据不用特意搬：升级换的是 releases/ 里的程序，配置、数据、 凭据与锁都在安装目录根上，升级不动它们。 工作目录里的 novabot.lock 只表示已经有一份程序在这个目录运行，novabot-container.lock 只表示已经有一个容器在用这个数据卷。这两个都不必备份；程序停着的时候可以删，下次启动会重新写一份。

事件输出客户端

事件输出的连接额度与等待时间已有默认值，现有配置直接生效，无需增加部署步骤。 总连接数默认 256，等待首帧默认 128，每对端地址默认 128，同时握手默认 64； 握手等待与单次写入、关闭等待默认均为 10000 毫秒。 新握手返回 HTTP 503 时按 Retry-After: 5 至少等 5 秒再试；需要更多面板时， 按日志指出的 novabot.core.event-stream 配置键调整正整数额度后重启。 同一代理或隧道接入的面板共用每来源额度。各键说明见附录 B。

升级后请在控制台「连接 → 外部面板」签发只读口令，让事件输出客户端在连接后首帧发送； 浏览器面板还需在 novabot.core.event-stream.allowed-origins 填写页面来源后重启；尚无有效只读口令时，启动日志会提示签发。 已有只读口令可继续使用。require-token 默认 true，已有配置即使填写 false 也按 true 运行， 配置文件无需手工迁移。口令只填在首帧里，连接地址和握手头中不填写口令。 页面来源的写法及客户端示例见附录 B。

页面来源按浏览器实际值填写，默认端口 80/443 会自动去掉；IPv6 主机须保留方括号，域名使用 ASCII 写法（国际化域名先转为 Punycode），不加末尾斜线。 保存时会检查写法；启动时若配置格式不合，事件输出暂停，程序和控制台照常启动，可在设置中修改后重启。

一键升级

使用外部程序触发的实例，升级后如有规则需要调整，控制台顶部会提醒管理员是哪几条 （启动日志里也有同样的提示）。请按附录 B 的事件命令写法 修改这几条规则的 command 并重启，提醒随之不再出现。程序会保留现有配置文件，没有提醒的规则可继续使用。

Linux 一键安装过的机器，重新跑一遍安装脚本就是升级：

cd NovaBot
git pull
./install.sh

程序装在安装目录的 releases/<版本>/ 下。这一跑会把新版装进 releases/<新版本>/， 上一版原样留在 releases/<上一版>/，更旧的版本目录删掉，正在跑的那一版也留着。 配置、数据、凭据与锁在安装目录根上，不随版本走。要装的版本已有实例在跑时， 脚本会停下不装——先把那个实例停掉再跑。

装完之后怎么走，安装脚本按机器上正在跑的是什么自己挑，五种情形（判定不用你管）：

• 另一个版本正在跑、没给 --no-switch（--no-switch 是安装脚本的可选参数，见第 3 章）：装完自动换到新版。安装脚本直接调换版工具，工具的输出接着印出。换成时最后一行是换回上一版的命令「换回上一版：sudo /usr/local/sbin/novabot-switch-version 5.7.8」，热交接与普通重启做成都是这一句。它前面那一行，热交接是「已换到 5.7.9，中间断了约 6 秒（起点到 ready）」，普通重启是「已换到 5.7.9。」。没换成时，最后一行才写明机器上的现况。换版没全部做成时，安装脚本带着换版工具的退码结束，收尾提示给两步：重试换版、看启动日志。
• 给了 --no-switch：只装不换，开机自启留在旧版；收尾提示给出换版命令，想换的时候自己跑。
• 没有版本在跑：安装时就把新版设为开机自启，收尾提示给出启动那一步。
• 旧单元 novabot.service（更早的 starbot.service）在跑：照下一节「老用户第一次升级」手动先停旧、再起新。
• --no-service，或机器上没有 systemctl：不建服务，也不装换版工具；收尾提示给出 start.sh 那条启动命令。

服务单元是模板单元 novabot@.service，实例名就是版本号，脚本每次安装都会 重写模板单元。开机自启什么时候切到新版：没有版本在跑的，装的时候切；有版本 在跑的前两种情形，等换版工具把新版换成了才切——装完还没换的当口机器重启， 起来的仍是旧版。

安装目录根上的 plugins/ 与 plugins-lib/ 留给你自己放第三方插件与依赖。 升级不碰这两个目录；发行包自带的内置插件与依赖在各版本目录里 （releases/<版本>/plugins/、releases/<版本>/plugins-lib/），随版本换新。 根上放的插件与依赖，每个版本启动时都会一起加载。

换版工具

装法一（Linux 一键安装、有 systemd）的机器上，换版本交给换版工具：

sudo /usr/local/sbin/novabot-switch-version <版本>

它把正在跑的那个版本换成你指定的版本：能热交接就热交接，不能就普通重启， 没成时把旧版本起回来。装法二与装法三没有它——目录不分版本，换法见本章 「手工升级」与「容器怎么升级」两节。

热交接与普通重启各在什么时候。三样都成立才走热交接：目标版本的构建信息里 写着 handover=1；旧版本此刻拿着单实例锁；整机可用内存不少于目标版本的 MemoryHigh（没设或读不到按 1.2G 算）。5.7.8 及更早的版本没有 handover=1。 第一次从这些版本升上来不经换版工具：旧服务还在跑时工具拒绝，印 「旧服务 novabot.service 正在运行。老用户第一次换到分目录，请先手动停掉旧服务，再起新版本。」 （更早的单元名是 starbot.service），这次什么都不改。照下一节「老用户第一次升级」 手动先停旧、再起新。那一次做完、已经按版本分目录之后，换回这些版本走普通重启， 因为目标没有 handover=1；从这些版本再换到带 handover=1 的新版也走普通重启， 因为它们没拿着单实例锁，三样凑不齐。三样缺任何一样，工具印出缺了哪样、改走普通重启。 热交接是先起新版本、让它到门口等锁，再停旧版本、由新版本接手；普通重启是先停旧版本， 再起新版本。机器上本来没有版本在跑时，谈不上换，工具直接普通启动目标版本。 开机自启只留在目标版本上，别的版本开着的会关掉。

先看一眼会怎么走。换之前可以先预演，只看不动、不改机器：

sudo /usr/local/sbin/novabot-switch-version --plan <版本>

第一行是「只看不动：把正在跑的实例换成 5.7.9 会怎么走。」接着逐行印三个条件：

• 「目标版本带 handover=1：是」或「目标版本带 handover=1：否」
• 「旧版拿着单实例锁：是」、「旧版拿着单实例锁：否」或「旧版拿着单实例锁：读不到」
• 读不到可用内存时，第三行是「可用内存不少于目标的内存上限（可用 读不到，上限 1.2G）：读不到」。上限取目标版本单元的内存上限（出厂单元设的是 1.2G）；改过就印改后的数，没设也按 1.2G。读得到时，「可用」和「上限」后面换成当时的数，冒号后面是「是」或「否」

最后一行：三样都成立，印「这次会走热交接：先起 5.7.9，等它到门口再停 5.7.8。」 缺了哪样，印「这次会走普通重启：」接上原因，再接「先停 5.7.8，再起 5.7.9。」 原因是下面这些句子里的一句或几句连在一起：「没有 handover=1。」「旧版没拿着锁。」 「读不到锁。」「内存不够。」「读不到可用内存。」例如只有第一句时，整行是 「这次会走普通重启：没有 handover=1。先停 5.7.8，再起 5.7.9。」

机器上没有分目录实例在跑时，不印上面三行，直接印 「现在没有分目录实例在跑，这次会普通启动 5.7.9。」

下面这些和真换是同一句，预演也不改机器。第一行仍是那句「只看不动」：

• 「有不止一份 novabot@ 在跑，这次什么都没改。」
• 「5.7.9 正在反复重启，这次什么都没改。」接着还有一行「看日志：journalctl -u novabot@5.7.9 -n 200 --no-pager」
• 「5.7.9 已经在跑，不用换。」印完就结束。
• 「旧服务 novabot.service 正在运行。老用户第一次换到分目录，请先手动停掉旧服务，再起新版本。」
• 「状态目录已在，但是符号链接或不是目录，这次什么都没改。」状态目录已经在、但是符号链接或不是目录时才印这句，而且只在目标版本或正在跑的版本带 handover=1 的时候查。

另外四句后面还会再补一行机器上的现况，说法与下面四种一样。 预演中途按 Ctrl-C 直接退出，不动机器。

两种各断多久、印什么。都只断一小会儿，热交接断得更短：做成时印 「已换到 5.7.9，中间断了约 6 秒（起点到 ready）」。这句里的秒数是旧版退出到新版就绪。 新版就绪后，先连账上正在播的直播间，其余直播间按放行间隔一间间连回来，排在后面的要多等一会儿。 这段空档照常记进这一场「未采集」的缺口。普通重启要把旧版停干净再起， 断得久些，做成时印「已换到 5.7.9。」，不印秒数。两种做成时都会附带印出回滚 命令「换回上一版：sudo /usr/local/sbin/novabot-switch-version 5.7.8」。

没成时起回旧版。换版中途任何一步没成，工具会把旧版本起回来（起不回来会 明说），最后一行写明机器上的现况。最后一行只有四种说法：

• 「机器上跑的是 5.7.9。」——一份版本正常在跑
• 「机器上跑的是 5.7.9；5.7.8 正在反复重启。」——一份在跑，另一份起不来、正被 systemd 反复拉起
• 「机器上没有版本在正常跑；5.7.9 正在反复重启。」——没有正常跑的，只有反复重启的
• 「机器上没有版本在跑。」——一份都没有

在跑的那份若是这次换下来的旧版，名字前带「旧版」二字；在跑的若是旧单元， 名字形如「旧服务 novabot」。开机自启没切成时，要关的每个版本、以及要开的目标版本，各自出错各印一句， 可能只有一句。要关的不止正在换下来的那一版，别的开着开机自启的版本也各算一个。 印出来的是「请手动执行：systemctl disable novabot@5.7.8」，要关不止一个时每个各印一句； 开目标是「请手动执行：systemctl enable novabot@5.7.9」。没有别的版本可关时，只有开目标那一句。 重新加载服务配置失败时，印「重新加载服务配置没有成功。」。这句里没有「请手动执行」； 该关的都关掉、目标也开上时，一句「请手动执行」都没有。同样退码是 1，最后一行照样带下面那一截。 有「请手动执行」时，命令前面没有 sudo，执行时自己加上。新版本已经在跑，照它印出的每一句改过来即可。 最后一行的现况里会再带一截：接在在跑的那份名字后面；没有正常在跑的，就接在 「没有版本在正常跑」或「没有版本在跑」后面。只有一个版本开着开机自启时，这一截是 「，开机自启在 5.7.8」；两个开着时，是「，开机自启在 5.7.8 和 5.7.9」； 三个或更多时，前面几个用顿号分开、最后一个用「和」连上，例如 「，开机自启在 5.7.7、5.7.8 和 5.7.9」； 一个都没开时，是「，没有版本设了开机自启」。

中途按 Ctrl-C。工具被打断会自己收拾，先印「换版被打断，正在收拾。」 要你动手的有两种。一种是开机自启没切成，照它印出的「请手动执行」改过来。 另一种是还没换成、旧版也没能起回来：最后一行照当时现况印。常见是 「机器上没有版本在正常跑；旧版 5.7.8 正在反复重启。」；旧版已经停下，才是 「机器上没有版本在跑。」。退码是 130。按 Ctrl-C 打断时不印 「旧版 5.7.8 没能起来。」（第 14 章那一条是对着这句写的）。处理仍照那一条： 两份日志都看，先把旧版救活。 接着按当时走到哪一步：

• 已经全部做成（新版在跑、开机自启已经切完）：印完那句就退出，退码是 0。
• 新版已经就绪、开机自启还没切完：先把开机自启切完。切成了印「已换到 5.7.9。」退出；没切成则退码是 1，新版在跑。重新加载服务配置失败时，一句「请手动执行」都没有，照上面「重新加载服务配置没有成功。」处理；有「请手动执行」时，照上面印出的每一句改过来。
• 还没换成：新版若已经启动就停掉；旧版若已经被停掉就起回来，起的时候先印「普通启动 5.7.8。」。旧版起不回来时，最后一行照当时现况印。常见是「机器上没有版本在正常跑；旧版 5.7.8 正在反复重启。」；旧版已经停下，才是「机器上没有版本在跑。」。起回来了，最后一行写明现况，说法与上面四种一样。退码是 130。

老用户第一次升级

旧版的一键安装是扁平布局：程序直接放在安装目录根上。从那种机器升上来、 第一次跑安装脚本时，脚本会先把旧程序搬进 releases/<旧版本>/（旧版本号从旧的 NovaBot.jar 里读），再装新版。内置插件、自带依赖与 lib/、tools/ 等都搬过去； 更早的 StarBotCore.jar 也一并挪进旧版本目录——它作为上一版的一部分留着， 再升一版才会跟着那个目录被删。

搬走的是与新包同构件名的旧 jar（构件名就是去掉版本号的那截文件名），其余—— 自己放的第三方插件与依赖、改过名的老内置件——不会被搬，留在根上。收尾列出的 「根上留下的使用者插件」就是根上 plugins/、plugins-lib/ 里剩下的全部 jar。 留下的这些启动时仍会被加载，与版本目录里新版自带的并存——确认不用的、与新版 自带依赖同名的，自己删掉，免得新旧两份一起加载。从 5.2 及更早升上来时 主程序与内置插件还叫旧名字，搬不走、也盖不掉，这些也在名单里，要自己删：

• starbot-onebot-adapter-1.0.0.jar
• starbot-onebot-adapter-napcat-extension-1.0.0.jar
• starbot-bilibili-1.0.0.jar
• starbot-novabot-console-1.0.0.jar
• starbot-report-1.0.0.jar

已发布的 5.2.0 及更早只有前三个插件 jar；后两个只在 5.3.0 发布前、目录还没改名的构建里有。

旧单元 novabot.service（更早的 starbot.service）只关掉开机自启：正在跑的不停、 单元文件留着，等你自己停；没在跑的删掉单元文件。旧单元上的覆盖设置不带到新单元， 收尾会列出这些目录——要继续用（比如调过的内存上限），按 附录 A 的做法在模板单元上重设。

分目录之间的升级如今交给换版工具（见上一节），这一节仍旧手动：先停旧版本， 再起新版本，中间会断一小会儿；顺序不能反：旧版本还没有单实例锁，新版本起来时 不会等旧版本放开，两份会同时连直播间、抢端口。换版工具在这种时候帮不上—— 它见到旧单元还在跑会拒绝：「旧服务 novabot.service 正在运行。老用户第一次换到 分目录，请先手动停掉旧服务，再起新版本。」这次什么都不改，就是要等你先手动 把旧单元停掉：

sudo systemctl stop <旧单元>
sudo systemctl start novabot@<新版本>
sudo journalctl -u novabot@<新版本> -f

具体停哪个、先做哪一步，收尾提示会写明。

上一版还在

升级后上一版没有被删：程序在 releases/<上一版>/，对应的实例是 novabot@<上一版>。 新版本有问题想切回去，先照本章备份一次，然后把上一版当作目标，再调一次换版 工具——升级做成时工具印的 「换回上一版：sudo /usr/local/sbin/novabot-switch-version 5.7.8」就是这条命令：

sudo /usr/local/sbin/novabot-switch-version <上一版>

工具照常选热交接或普通重启（换回 5.7.8 及更早的版本走普通重启），没成时把 新版本起回来，开机自启跟着切。机器上没有换版工具时（装法二、装法三，或装的 时候给了 --no-service），才手动四条：

sudo systemctl stop novabot@<当前版本>
sudo systemctl start novabot@<上一版>
# 确认上一版起来了之后
sudo systemctl disable novabot@<当前版本>
sudo systemctl enable novabot@<上一版>

手工升级

不用脚本的机器（macOS、Windows，或不想让脚本碰系统的），目录不分版本， 程序、配置与数据都在同一个目录里，照这个顺序做：

1. 停止服务
2. 备份 application.yml、datasource.json、cookies.json、cookies.key
3. 用新版本的产物整个换掉 NovaBot.jar 与 lib/
4. plugins-lib/ 里新包自带的 jar 按名字删旧放新，自己放的留下
5. plugins/ 不要整个替换，只按名字换这五个内置插件并删旧版（<版本> 处换成新版本号）：
6. nova-onebot-adapter-<版本>.jar
7. nova-onebot-adapter-napcat-extension-<版本>.jar
8. nova-bilibili-<版本>.jar
9. nova-console-<版本>.jar
10. nova-report-<版本>.jar
11. 保留原有的 application.yml 与 datasource.json
12. 启动，看日志有没有告警

容器怎么升级

容器里的目录也不分版本。换新镜像、重建容器就是升级。容器每次启动都会用镜像里的 NovaBot.jar 与 lib/ 盖掉卷 /app 上的同名文件，并按新文件名换内置插件； plugins-lib/ 里镜像自带的依赖也按构件名换新，自己放的留下（与上面手工升级 第 4 步同一个规则）。要自己动手的：

• 旧名插件与 StarBotCore.jar 容器入口都不删，要自己删

配置、凭据与数据都在卷里，容器重建不丢，前提是卷挂在 /app （见第 3 章）。

配置要不要跟着改

从 5.4 及以后升级，配置一般直接沿用，application.yml 与 datasource.json 保留原样。

启用控制台二次验证的实例，首次启动会自动在主配置文件旁创建 <主配置文件名>.totp-state（默认是 application.yml.totp-state），之后换版保留此文件。 通常无需手工操作；单独挂载配置文件或主配置目录只读的部署，需要为此文件及其所在目录 提供可写的持久化存储。文件属主应为运行程序的用户，权限为 600。 只有记录文件无法读写或内容不完整，或服务器时钟往回校正过时，日志与终端才会提示处理方法； 提示按错误级别输出，日志级别设为 OFF 时看不到。未启用二次验证的实例无需调整。 文件为空或内容不完整时，停服务并从备份恢复该文件后再启动；权限无法设置时，调整文件属主和存储权限后重试。 服务器时钟往回校正过之后，按提示等待到指定时间再登录；急需进入时，可将 novabot.core.config-ui.auth.operator-token 临时改为 true 后重启，用启动日志里的地址进入。 这个地址按 INFO 级别输出；日志只看错误或已关闭时，还需把 novabot.core.log.console 或 novabot.core.log.file 临时改为 INFO。用完把日志设置改回原值，并把启动令牌开关改回 false。

升级到金额显示、静音时段、命令开关按通道各设的版本时，第一次启动会把原来按群存的这三样 照抄进 datasource.json 里这个群下的每一条通道，群里看到的和升级前一样；改写前先自动备份一份。 原来的记录还留在 state.json 里，退回旧版时照旧用得上。第三方插件的命令开关不抄，仍按群存。

从 5.3 及更早升级，旧根键 starbot: 下的设置不再读取。启动日志会有一条 WARN 说明没被读取、该挪到哪：程序不替你改配置文件，请手工把它们挪到新根键 novabot: 下 （还没有新根键的，把 starbot: 改名即可），改完重启。最短对照：

# 改前（不会被读取）
starbot:
  bilibili:
    account:
      cookie-path: cookies.json

# 改后
novabot:
  bilibili:
    account:
      cookie-path: cookies.json

用了统一登录、而“统一登录 · 回调地址”（novabot.core.config-ui.oidc.redirect-uri）留空的， 升级后请在「设置 → 高级选项 → 登录与安全 · 高级」里的「统一登录 · 回调地址」 填写与账户中心登记的完全一致的完整回调地址，保存后重启。 没填时启动日志会有一条 WARN，管理员打开控制台后，各页顶部也会有同样的填写提醒； 填好并重启后提醒消失。留空时只有用 localhost、127.0.0.1 或 ::1 打开控制台才能用统一登录。 详见附录 E。

个别整节挪过位置的设置，根键还是 starbot: 时挪位那条提醒不会出。先按那条 WARN 把根键改成 novabot:、改完重启；下一次启动，还写在旧位置的整节才会被点名。 从上游 StarBot 迁移还有别的差异，见附录 D。

怎么备份

直播数据可以用一条命令同步到本机另一个目录或另一台机器：

bash /opt/starbot/tools/data-backup.sh <数据目录> user@备份机:/var/backups/novabot

数据目录就是装着 sessions.jsonl 与 details/ 的那个目录，也就是设置里 「直播数据 · 文件路径」所在的目录：一键安装默认在安装目录根上（装在 /opt/starbot 的话就是 /opt/starbot，程序在它下面的 releases/ 里），手动安装就是程序目录， 容器是 /app。同步只增不删——目标上已有的文件不会被去掉；reports/、releases/ 与 *.tmp 不同步，releases/ 里是各版本的程序，不算直播数据。

每天自动跑一次：把安装目录下的 novabot-backup.service 与 novabot-backup.timer 拷到 /etc/systemd/system/，改 service 里的目标路径（安装目录若不是 /opt/starbot， 脚本路径和数据目录一并改），然后：

sudo systemctl daemon-reload
sudo systemctl enable --now novabot-backup.timer

默认凌晨 4 点跑，改 novabot-backup.timer 里的 OnCalendar 可以换时间点。 恢复：先停服务，再从备份目录拷回数据与配置，不拷程序件；拷完再启动。

• 数据：data.json、state.json、sessions.jsonl、snapshots.jsonl、event-stream-tokens.jsonl 与 details/、timeline/ 两个目录
• 配置：application.yml、datasource.json、template-defaults.json、cookies.json、cookies.key
• 二次验证：主配置文件旁的 <主配置文件名>.totp-state，默认是 application.yml.totp-state，与主配置文件一起备份、恢复；主配置放在别处的，也一并备份那个目录里的此文件
• 备份里若有明文迁成加密时留下的 cookies.json.plain.bak，不用拷回，程序不读它。它是明文凭据，备份只增不删，安装目录里删掉了备份里也还留着——恢复后确认能正常登录，就把备份里那份也删掉
• 程序件别拷回：一键安装的程序在 releases/ 下，备份不同步 releases/，本来就带不上；手动安装与容器的备份里会带着备份那天的 NovaBot.jar、lib/、plugins/、 plugins-lib/，整份拷回会把旧 jar 混进新版
• 安装目录根上的 plugins/ 与 plugins-lib/（手动安装则是 plugins/ 里除了手工升级列的五个内置插件之外）是你自己装的第三方插件与依赖，恢复时要从备份里拷回；5.2 及更早的 starbot- 开头旧名插件确认不用就删掉，别拷回

订阅名单、第三方插件的命令开关、绑定关系都存在 state.json 里，它与数据文件在同一目录， 按上面备数据时会一起带上。换机器时少备了它，群里那些订阅就得重新订一遍。 按主播的命令开关、金额可见、静音时段跟推送配置一起存在 datasource.json，随配置一起备。

登录凭据会不会掉

一般不会。 扫码登录走的是电视端接口，拿到的令牌有效期 180 天，到期前 30 天 程序会自动续期（设置项「登录凭据 · 自动续期」，默认开启）。 启动日志会明说拿到的是哪一种凭据，出问题先看这一行：

• 「已取得可自动续期的登录令牌, 有效期至 X」——正常，不用管
• 「已取得网页端刷新口令」或「未取得任何刷新口令」——退化了，重新扫一次码即可

退化的成因是个已知限制：网页端扫码登录时服务端把持久化刷新口令返回为空， 所以改走了电视端接口。拿不到口令时续期直接跳过，不会有副作用，只是没法自动续。

掉登录的表现是动态推送停止（直播推送不受影响），首页健康自检会明确告警，开着告警且配了告警通道时还会发告警通知， 重新扫码即可。健康自检写着「未取得刷新口令，无法自动续期」的，说明这份凭据是旧版本或 设置项「扫码登录方式」改成 web 时扫出来的，到连接页「哔哩哔哩」卡点「退出登录并重新扫码」 即可换成可续期的。频繁掉登录的其它成因见第 14 章。

接下来

升级备份都有了，出问题怎么查、去哪问： 第 14 章　遇到问题怎么办。