[Flutter Desktop] Windows 应用产品化指南 (三)：版本迭代与维护 SOP

发表于 分类于 ， ，
软件发布不是一锤子买卖。本文制定了 Flutter Windows 应用在后续功能迭代、Bug 修复时的标准化发布流程 (SOP)，涵盖版本号同步、安装包升级策略及 Git 规范。

一、 引言

在完成了应用的首次发布 (v0.0.1) 后，我们进入了漫长的维护期。当我们在代码中修复了一个 Bug 或新增了功能（例如支持了新的串口协议），如何规范地发布 v0.0.2？
Windows 软件的更新不像 Web 网页那样刷新即用，它涉及到注册表覆盖、文件替换等机制。因此，严格遵守版本迭代 SOP 至关重要。

二、 核心原则：AppId 守恒定律

在 Inno Setup 脚本中，有一个至关重要的字段：AppId。 

1
[Setup] AppId={{A1B2C3D4-...}

  • 原则： 永远不要修改 AppId。

  • 原因： Windows 依靠这个 ID 识别“这是同一个软件”。

    • 如果你保持 AppId 不变，用户安装 v0.0.2 时，安装程序会自动检测到旧版 v0.0.1，并执行覆盖升级（保留用户数据，更新程序文件）。

    • 如果你手贱改了它，Windows 会认为这是两个完全不同的软件，导致用户电脑上同时出现两个“PV Monitor System”，造成灾难。

三、 版本升级 SOP (Checklist)

每次发布新版本（例如从 v0.0.1 -> v0.0.2），请严格按顺序执行以下 “四点同步法”：

✅ 1. 修改 Dart 核心配置

文件： pubspec.yaml

YAML

1
2
# 修改 version 字段
version: 0.0.2+1

✅ 2. 修改 UI 显示

文件： lib/ui/main_screen.dart

Dart

1
2
// 这是一个容易遗漏的硬编码点
Text("V0.0.2 Beta", style: ...)

✅ 3. 修改 Windows 元数据

文件： windows/runner/Runner.rc

代码段

1
2
3
// 找到 VS_VERSION_INFO
VALUE "FileVersion", "0.0.2"
VALUE "ProductVersion", "0.0.2"

✅ 4. 修改打包脚本

文件： installer_script.iss

代码段

1
2
#define MyAppVersion "0.0.2" 
; OutputBaseFilename 也会随之变为 PV_Monitor_Setup_v0.0.2

四、 构建与发布 SOP

1. 编译 Release

修改完上述四个文件后，执行编译。务必先 Clean，因为 Runner.rc 的修改往往需要重新链接才能生效。

PowerShell

1
2
flutter clean
flutter build windows --release

2. 制作安装包

  1. 打开 installer_script.iss。

  2. 点击 Build -> Compile。

  3. 检查 installer_output 目录，确认生成了 PV_Monitor_Setup_v0.0.2.exe。

3. 验证 (Smoke Test)

在发布给客户前，先在自己电脑上模拟一次**“覆盖安装”**：

  1. 确认电脑上已安装 v0.0.1。

  2. 双击运行 v0.0.2 安装包。

  3. 观察是否提示“目标文件夹已存在”（正常），安装后打开软件，检查顶部栏版本号是否变成了 V0.0.2。

4. Git 归档

PowerShell

1
2
3
4
git add .
git commit -m "chore: bump version to v0.0.2"
git tag v0.0.2
git push origin main --tags

5. 分发

上传到 Gitea Release 和 阿里云下载站。

五、 进阶：关于自动更新 (OTA)

目前的 SOP 是“被动更新”，即用户需要自己去下载新包覆盖。 如果未来需要实现**“软件内检测更新”**，可以在 Dart 层实现以下简易逻辑：

  1. 在阿里云 OSS 放一个 version.json：{"latest": "0.0.2", "url": "..."}。

  2. App 启动时请求这个 JSON。

  3. 对比 package_info_plus 获取的本地版本与 latest。

  4. 如果发现新版，弹窗提示，并调用 url_launcher 打开浏览器下载链接。