企业官网建设流程全解析

sau bilibili 自动下载 biliup 失败时，如何用 gh-proxy 辅助访问 GitHub Release 排障？

【免费下载链接】social-auto-upload自动化上传视频到社交媒体：抖音、小红书、视频号、tiktok、youtube、bilibili项目地址: https://gitcode.com/GitHub_Trending/so/social-auto-upload

运行sau bilibili login、sau bilibili check或sau bilibili upload-video时，程序会先自动准备biliup：首次运行如果本地还没有biliup，会去 GitHub Release 下载；上游有更新时也会先自动更新再执行。在国内网络环境下，这一步经常表现为“首次运行很慢”或直接失败——安装说明 明确提到，国内网络访问 GitHub Release 较慢时，可先用https://gh-proxy.com/或https://gh-proxy.org/辅助访问对应 release 地址排障。本文围绕这一现象，给出项目文档中给出的检查项、release 地址的确认方式，以及 biliup 就绪后的验证命令。

先判断失败发生在哪个环节

biliup的自动准备逻辑实现在 uploader/bilibili_uploader/runtime.py，流程是：

1. 请求 GitHub 的 latest release 接口（https://api.github.com/repos/biliup/biliup/releases/latest）；
2. 按当前系统选出对应的 release 资产并下载；
3. 解压出可执行文件，写入本地运行时目录~/.social-auto-upload/tools/biliup/<平台>/，并记录版本号到同目录的version.txt。

常见问题文档 对“首次运行很慢”的解释是：这是正常情况，通常因为程序正在自动下载biliup。而运行前提说明 指出：一旦本地已经准备好biliup，后续命令会直接复用；如果网络无法访问 GitHub Release，Bilibili 命令会失败。所以排障前先区分两种现象：

• 命令卡住很久：可能只是下载慢，先等一轮完成；
• 命令直接报错退出：大概率是接口请求或资产下载失败，进入下面的检查。

排障检查项

常见问题文档 对“自动下载失败”给出的检查清单是：

• 当前网络是否能访问 GitHub；
• GitHub Release 是否可访问；
• 本地目录是否有写权限（运行时目录在用户主目录下的.social-auto-upload/tools/biliup/，见 runtime.py 中的get_biliup_runtime_root）；
• 国内网络较慢时，用https://gh-proxy.com/或https://gh-proxy.org/辅助访问对应 release 地址排障。

其中第三项容易被忽略：下载本身可能成功，但解压、写入运行时目录失败也会表现为“下载失败”，此时重点检查的是目录写权限，而不是网络。

确认当前系统对应的 release 地址

自动下载选资产是按“系统-架构”匹配的，runtime.py 中的_select_release_asset定义了各平台对应的资产文件名特征：

不在上表中的平台会抛出Unsupported biliup platform；Release 里找不到匹配资产时抛出No matching biliup release asset found for platform。排障时先确认自己属于哪一行，再用对应的资产名去核对 release 地址。

用 gh-proxy 访问 release 地址验证

安装说明 给出的示例是（文档示例，v1.1.29为示例中的版本号，实际最新版本以程序查询结果为准）：

https://gh-proxy.org/https://github.com/biliup/biliup/releases/download/v1.1.29/biliupR-v1.1.29-aarch64-linux.tar.xz

按示例的格式，gh-proxy 地址的拼法是：代理前缀 + 原 GitHub release 下载地址，即https://gh-proxy.org/或https://gh-proxy.com/后接https://github.com/biliup/biliup/releases/download/<版本>/<资产文件名>。版本号和资产文件名要按上一节的平台表替换成自己系统对应的值，上面的示例对应的是 aarch64 Linux。

用浏览器或下载工具访问这个拼好的地址，判断结果分两种：

• 能正常下载：说明 release 资产本身可访问，问题出在本机到 GitHub 的直连链路，或本地目录写权限；
• 仍然失败：说明资产地址本身不可达（如版本、资产名拼错），回到平台表核对文件名，或检查 gh-proxy 前缀是否拼全。

biliup 就绪后的验证

自动下载链路修好后，重新运行触发命令即可，例如：

sau bilibili login --account <account> sau bilibili check --account <account> sau bilibili upload-video --account <account> --file videos/demo.mp4 --title "示例标题" --desc "示例简介" --tid 249

<account>是用户自定义的account_name，一个account_name对应一个账号文件。验证方式以 CLI 契约 为准：sau bilibili check --account <account>的预期输出是valid或invalid。

结合代码行为还可以多确认一点：version.txt里记录的版本号与上游 latest 不一致时会触发更新；如果请求 GitHub 失败但本地已有可执行文件，程序会直接复用本地版本（见 runtime.py 中ensure_biliup_binary的实现）。因此排障时可以查看~/.social-auto-upload/tools/biliup/下是否已有对应平台目录和二进制，判断“下载失败”究竟是没有下下来，还是后续更新检查失败。

边界与限制

• 文档的官方口径是“用户不需要手动安装biliup”，gh-proxy 在文档中的定位是“辅助访问对应 release 地址排障”，用于确认资产可达性；程序自身的下载仍然走 GitHub 直连地址。
• 本项目 Bilibili 集成会自动跟随上游biliup最新 release，上游命令行为变化可能影响 CLI；这类问题要同时确认当前下载到的biliup版本和上游 release 是否有最近变更，与“下载失败”是两条不同的排查线（见常见问题文档 第 6 节）。
• 如果 biliup 已就绪但check返回invalid，常见原因是账号文件不存在、登录信息已失效或biliup renew失败，建议重新执行sau bilibili login --account <account>，属于账号问题而非下载问题。
• sau bilibili login需要在本地真实终端里执行；非交互环境下触发会报not a terminal，这不是 biliup 下载链路的问题。

【免费下载链接】social-auto-upload自动化上传视频到社交媒体：抖音、小红书、视频号、tiktok、youtube、bilibili项目地址: https://gitcode.com/GitHub_Trending/so/social-auto-upload