跳到主要内容

⚙️ 选择你的更新策略

更新策略 = GeneralUpdate 用什么方式来发现和下载新版本。

根据你有没有后端服务、是否需要节省带宽、是否需要用户感知，选择一个适合你的策略。

先理解：更新策略的本质​

不管哪种策略，最终都是回答 3 个问题：

① 去哪查有没有新版本？    ② 去哪下载更新包？    ③ 怎么下载？
    │                        │                      │
    ├ 自己查（轮询）          ├ 自己的服务器         ├ 全量下载
    ├ 服务端通知（推送）      ├ 对象存储 OSS         └ 只下载差异部分
    └                        └

策略快速选择表​

看不懂术语没关系，先看这一列就行：

你的情况推荐策略一句话说明
有后端服务，新手入门① 标准最简单的方案，服务端返回版本信息，客户端下载更新
没有后端，只想把包放云存储② OSS把更新包上传到 S3/MinIO，零服务端成本
带宽有限，用户量大④ 差分每次只下载有变化的部分，省 60-90% 流量
需要强制用户升到最新（跳过中间版本）⑤ 跨版本用户从 v1.0 直升 v3.0，不用逐个版本升
用户无感知自动更新③ 静默后台下载完，下次启动自动生效
需要紧急推送安全补丁⑥ 推送服务端主动告诉客户端"立刻更新"

逐个策略详解​

① 标准客户端-服务端（推荐新手入门）​

适用场景：你有后端服务（如 GeneralSpacestation），想快速实现自动更新。

流程：客户端 → 问服务端"有新版本吗？"
      服务端 → 返回版本列表
      客户端 → 下载更新包 → 启动升级

优点：实现最简单，1 个 API 接口就能跑起来 缺点：需要部署和维护后端服务

② OSS 对象存储​

适用场景：你没有后端服务，但有对象存储（阿里云 OSS / AWS S3 / MinIO）。

流程：客户端 → 定期读取 OSS 上的 versions.json
      OSS → 返回版本列表
      客户端 → 从 OSS 下载更新包 → 启动升级

优点：零服务端，成本最低 缺点：不区分主程序和升级程序的更新包；Bucket 要设置好权限

③ 静默更新​

适用场景：用户不需要看到更新过程，后台静默完成。

流程：客户端在后台定期检查 → 发现新版本 → 静默下载
      下载完成后 → 通知用户"更新已下载，是否重启？"
      或：下次启动时自动生效

优点：用户体验好，不打扰 缺点：需要处理"下载完但用户不重启"的版本状态 轮询频率建议：30-60 分钟一次（太短耗电/流量，太长用户等得久）

④ 差分更新​

适用场景：你的更新包很大（>100MB），用户量多，想省带宽。

流程：服务端生成"补丁"（只记录新旧版本之间的差异）
      客户端下载补丁 → 本地合成新版本

优点：节省 60-90% 的下载量 缺点：服务端需要额外构建差分包；大文件（>2GB）可能触发整数溢出

⑤ 跨版本更新（CVP）​

适用场景：你的用户版本分散（有人还在 v1.0，有人是 v2.5），都需要升到 v3.0。

流程：服务端保留所有版本的升级路径
      v1.0 用户 → 直接下载 v3.0 全量包
      v2.5 用户 → 只下载 v2.5→v3.0 的差分包

优点：用户不用逐个版本升级 缺点：服务端需要额外构建和维护版本跳转逻辑

⑥ SignalR 推送​

适用场景：需要紧急推送安全修复，不能让用户等轮询。

流程：服务端通过 SignalR 连接主动推送"有新版本"
      客户端立刻开始下载更新

优点：实时推送，秒级响应 缺点：需要额外部署 SignalR Hub；断线后要回退到轮询

混合策略组合​

实际项目中，这些策略可以组合使用：

组合适合谁怎么做
① 标准 + UI几乎所有人标准检查 + 显示下载进度条
② OSS + ④ 差分无后端 + 省带宽更新包放 OSS，只下载差量
③ 静默 + ① 标准后台服务定时间隔检查，后台下载
⑤ 跨版本 + ⑥ 推送强制升级服务端推送"请立即更新"，跳过所有中间版本

如果你不确定选哪个​

有后端服务？
├── 是 → ① 标准（先跑起来再说）
│       以后需要时再加 ④ 差分 或 ③ 静默
│
└── 否 → ② OSS（零成本起步）
        把更新包上传到 S3/MinIO

这个方案不会错。先跑通再优化。

需要留意的事情​

#问题建议
1NuGet 版本不一致导致 "Method not found"Client 和 Upgrade 的 NuGet 版本必须完全一致
2OSS 模式不区分 Main/Upgrade 更新这是 OSS 的正常限制，接受即可
3升级程序必须放在 update/ 子目录从第一个版本就建好这个目录结构
4Linux/macOS 不支持 Bowl 崩溃守护只有 Windows 可以用 Bowl
5差分包不要超过 2GB大文件用全量包

相关页面​