升级都是基于采用安装包发布的应用。
对于绿色免安装版本（主要是指windows平台下portable版本）不适用。
Electron自带的升级框架
优点
- 包含了版本检查逻辑及回调
- 实现了下载安装升级逻辑
缺点
- 限定了发布版本的服务器（GitHub）
- 每次都是全量更新
electron-builder的升级框架
优点
- 包含了版本检查逻辑及回调
- 实现了下载安装升级逻辑
- 支持多种版本服务器，包括自搭建的“通用服务器”
- 支持alpha/beta/latest版本更新策略
- 支持灰度发布（按用户百分比）
- 支持增量更新，实现了增量更新失败时转全量更新的策略（目前只有windows版的，项目组据说计划增加mac版本的增量更新）
- 支持构建时自动发布版本到服务器
- *支持降级更新
缺点
- 版本更新检查基于package.json中的version字段值，其值只支持三段式的版本号，无法定制。具体规则见smerv
常见问题
[error] Cannot download differentially, fallback to full download: Error: Cannot parse blockmap xxxxxx, error：xxxxxx
说明上传服务器的blockmap文件有问题，请根据给出的错误信息做相应处理即可。大多数可能的情况是blockmap文件在解压的时候出现问题，日志内容大概是：
Cannot download differentially, fallback to full download: Error: Cannot parse blockmap "https://api.github.com/repos/VitruxPT/w-assistant/releases/assets/18470277.blockmap", error: incorrect header check, raw data:...
blockmap文件是编译生成的，所以如果上传服务器的时候没有出现文件损坏的话，那就一定是编译时的问题，可能是本地的electron-builde和electron-updater的版本太低，请确保electron-builder使用22.8.0以上， electron-updater使用4.3.4。因为之前的版本里面存在生成blockmap文件的bug，具体可查看项目的github页面。
- 服务器返回blockmap的mime-type不对导致parse error
在服务中设置.blockmap后缀文件的mime-type：multipart/byteranges
关于绿色免安装版本的升级
其实也并不是完全不能，除了常规的自己实现一套检查逻辑之外，其实利用electron-updater的也是可以做到的：
- 自己构造升级检查所需的latest.yml(alpha/beta 也一样，只是具体的channel值不一样)，并同对应的新版本exe文件放在服务器上
- 在electron-updater的版本更新检查回调中提示用户升级
- 下载完成时要求用户选择存放目录，并提醒用户运行新版本只能是使用其选择的目录下的exe文件
- 用户选择目录后，实现将electron-updater下载的exe从升级缓存目录移动到用户选定的目录
注意
由于绿色免安装版本本身机制限制，升级只能是全量升级（更换exe文件）无法做增量更新
