后续怎么更新版本
部署跑通以后，有新版 danmu_api 时，不需要重新走一遍完整部署教程。先按你现在的部署方式选择下面的标签页，更新完成后再回到页面底部做一次自检。
更新前先记住
- 云平台一般是：同步 GitHub fork → 平台自动重新部署。
- Docker / NAS 一般是：拉取新镜像 → 重建容器。
- Node.js / Termux 一般是：
git pull→npm install→ 重启服务。 - 安卓 App 日常优先更新 API 核心，不是先重装 APK。
先选你的部署方式
适用于从 GitHub fork 自动部署的方式：
- Vercel
- Netlify
- Cloudflare Workers
- EdgeOne Pages
这类平台的更新链路通常是：
- 在 GitHub 里把自己的 fork 同步到上游新版。
- 云平台检测到 fork 有新提交。
- 云平台自动重新构建 / 部署。
- 部署成功后，原来的访问地址就是新版。
第 1 步：进入你自己的 fork 仓库
先打开你自己账号下的 danmu_api 仓库，不是 huangxd-/danmu_api 上游仓库。
仓库地址一般长这样：
https://github.com/你的GitHub用户名/danmu_api点仓库顶部的 Actions。
第 2 步：第一次使用时，先启用 Workflows
如果这是 fork 仓库第一次打开 Actions，GitHub 可能会提示工作流被停用。先按页面提示启用。
看不到这个提示也没关系，说明可能已经启用过，继续下一步。
第 3 步：打开并启用 Fork Sync
左侧打开 Fork Sync。
如果页面显示 Disabled，点右侧 Enable workflow。
启用成功后，页面会提示 Workflow enabled successfully。
第 4 步：手动跑一次 Fork Sync
第一次建议手动跑一次，确认自动同步链路是通的：
- 点右侧
Run workflow。 - 分支保持
main。 - 再点绿色
Run workflow。
这次运行变成绿色成功后，说明你的 fork 已经能同步上游更新。以后它会按工作流配置自动检查更新；想立刻检查时，也可以回这里手动运行一次。
第 5 步：等云平台自动部署完成
Fork Sync 成功后，云平台通常会检测到你的 fork 多了新提交，然后自动重新部署。
各平台看这里：
- Vercel：到项目的
Deployments看最新记录是否变成Ready。 - Netlify：到项目的
Deploys看最新记录是否成功。 - Cloudflare Workers：确认项目连接的是你自己的 fork，然后看最新部署记录是否成功。
- EdgeOne Pages：到 Pages 项目的部署记录里看最新构建是否成功。
如果你是第一次确认部署链路，可以回到对应部署页检查：
自动同步失败怎么办
如果 Fork Sync 变红，常见原因是上游改到了 .github/workflows/*.yml 这类工作流文件，GitHub 默认令牌没有权限自动同步这些文件。
遇到这种情况，先不要反复点运行。可以继续看 常见问题。
Hugging Face Space 这条线有两层同步：
Fork Sync：把上游新版本同步到你的 GitHub fork。Sync to Hugging Face Space：把你的 fork 推到 Hugging Face Space，Space 再重新构建。
第 1 步：先启用 Fork Sync
和其它云平台一样，先回你自己的 GitHub fork，启用并运行 Fork Sync。
如果你还没做过，按「云平台」标签页里的第 1 到第 4 步做一遍。
第 2 步：确认 Hugging Face 同步工作流已启用
Hugging Face 还需要 Sync to Hugging Face Space 工作流。部署页已经写了完整步骤，可以回到 Hugging Face Space 部署 对照检查。
第 3 步：看同步结果和 Space 状态
GitHub Actions 同步成功后，回 Hugging Face Space 页面等它重新构建。状态重新变成 Running 后，再打开你的 hf.space 地址测试。
如果失败，优先检查这几项：
- GitHub fork 的
Fork Sync是否成功。 Sync to Hugging Face Space工作流是否成功。- Space 页面是否重新进入
Running状态。 - Space 里的必要变量是否还在，例如
TOKEN、ADMIN_TOKEN。
Docker、1Panel 和 NAS 这几种，本质上都是更新容器镜像。
1Panel 面板部署
1Panel 面板里通常按这个思路处理：
- 进入
容器/编排相关页面。 - 找到
danmu_api对应的 Compose 项目或容器。 - 拉取新镜像。
- 重新创建 / 重建容器。
- 等容器状态恢复运行。
如果已经加了 Watchtower，先看 Watchtower 是否还在运行。
对应完整流程可以回到 Docker 部署 查看。
Docker 命令行部署
如果你是命令行启动的 Docker，可以进入服务器后执行一轮手动更新。下面示例假设容器名叫 danmu-api，实际以你自己的容器名为准。
docker pull ghcr.io/huangxd-/danmu_api:latest
docker stop danmu-api
docker rm danmu-api然后用你原来的 docker run 命令重新启动。
如果你当初用的是 Compose：
cd /你的/docker-compose/目录
docker compose pull
docker compose up -d如果你加了 Watchtower，它会按配置自动检查并更新镜像。
NAS / 家用网络部署
NAS 页面主要讲怎么把容器跑起来。后续版本更新仍然按 Docker 思路处理：
- 如果 NAS 面板支持 Compose 项目重建，就重新拉取镜像并重建项目。
- 如果你加了 Watchtower，就检查 Watchtower 日志和容器更新时间。
- 如果 NAS 面板功能不够，可以参考 Docker 部署 的命令行版。
注意
更新容器前，先确认你的 .env、Compose 文件、缓存目录挂载路径没有丢。不要为了更新镜像直接删除整个项目目录。
电脑本地 Node.js 和 Termux 都是源码运行。更新程序版本时，通常是进入项目目录后 git pull，再重新安装依赖并启动。
电脑本地 Node.js
先在运行 npm start 的终端里按 Ctrl + C 停掉服务，再执行：
cd ~/danmu_api
git pull
npm install
npm start如果你的项目目录不在 ~/danmu_api，就把第一行换成自己的实际目录。
Termux 手机部署
先在 Termux 里按 Ctrl + C 停掉服务，再执行：
cd $HOME/danmu_api
git pull
npm install
npm start先确认自己是 git clone 下载的
如果你当初不是用 git clone 下载，而是下载 zip 解压，git pull 不适用。建议重新按对应部署页下载代码，并先备份旧目录里的配置文件。
相关页面：
安卓 App 的日常更新重点不是先升级 APK，而是在 App 里更新 API 核心。
进入 App 后：
- 底部点 核心。
- 进入 API 核心管理 页面。
- 选择你正在用的核心，例如 稳定版。
- 点对应卡片里的 检查更新。
- 按 App 提示完成更新后，再回首页确认服务正常运行。
图里底部已经选中 核心，每个核心卡片里都有 检查更新 按钮。你用稳定版就检查稳定版；用开发版或自定义版，就检查对应卡片。
只有 App 外壳本身需要新版功能、修复安装问题，或者项目说明明确要求更新 APK 时，才去下载新版 APK。APK 下载和安装步骤看 安卓 App 部署，API 核心更新示例也放在 安卓 App：以后怎么更新 API 核心。
更新后怎么确认成功
无论哪种部署方式，更新完成后都建议重新跑一遍自检：
- 打开你的 LogVar 弹幕 API 地址。
- 进入 接口调试 或 弹幕测试。
- 测一遍自动匹配和手动匹配。
- 再回播放器确认弹幕能正常加载。
详细步骤看 部署后自检。
更新失败时先看哪里
- 云平台更新后还是旧版本：先看 GitHub fork 是否真的有新提交，再看平台最新部署是否成功。
- Docker 更新后打不开：先看容器是否运行、端口是否还是原来的映射、
.env是否还在。 - Node.js / Termux 更新后启动失败：先看
npm install是否报错，再看 Node.js 版本是否过旧。 - 安卓 App 更新核心失败：先确认网络可访问下载源，再回到 App 首页确认服务是否仍在运行。
如果仍然无法定位问题，继续看 常见问题。