Wails2 系列 09：构建、版本与发布：从开发结构走向可发布应用

适合读者

适合已经能本地运行 Wails 项目，并准备管理版本、构建产物和发布流程的开发者。

问题场景

很多项目开发时结构还算清楚，但一到发布就开始靠手工记忆：先构建前端，再构建 Wails，再改版本号，再打安装包，再上传 Release。哪个步骤忘了，产物就可能版本不对、资源没更新或平台配置缺失。

Wails 项目的发布结构，应该和开发结构一样清晰。

项目观察

当前项目中可以观察到几个发布相关边界：

wails.json：Wails 项目的构建和前端命令配置。
scripts：构建前后的辅助脚本，例如同步版本信息。
build：平台图标、安装包、manifest 等资源。
internal/buildinfo：运行时可读取的版本、提交和构建时间。
README.md：记录发布流程。

这些内容共同构成了从开发到发布的链路。

拆分原则

发布流程里至少要区分四类内容。

第一类是 Wails 配置。它告诉 Wails 如何安装前端依赖、如何构建前端、开发服务器怎么启动。

第二类是构建资源。图标、manifest、安装包模板等不属于业务代码，应放在明确目录。

第三类是版本信息。版本号、commit、构建时间最好能在构建时注入，而不是靠手改多个文件。

第四类是自动化流程。发布步骤应该写进脚本或 CI，而不是只存在于某个人的记忆里。

改造示例

一个清晰的发布结构可以是：

.
├── wails.json
├── build/
│   ├── icons/
│   └── installer/
├── scripts/
│   ├── sync-version.mjs
│   └── generate-buildinfo.mjs
└── internal/
    └── buildinfo/

版本信息可以通过构建时生成：

package buildinfo

var Version = "dev"
var Commit = "unknown"
var BuildTime = ""

应用服务只读取这些信息：

type AppInfo struct {
    Version   string
    Commit    string
    BuildTime string
}

发布流程可以被描述成稳定步骤：

1. 从 tag 或 package 读取版本号
2. 同步到 Wails 配置
3. 生成 buildinfo
4. 构建前端资源
5. 构建平台安装包
6. 上传 Release

关键不是必须使用某一种 CI，而是不要让发布依赖临时手工操作。

检查清单

wails.json 中的前端安装、构建和开发命令是否清楚？
图标、manifest、安装包配置是否集中在构建资源目录？
版本号是否有单一来源？
应用内展示的版本信息是否来自构建注入？
发布步骤是否被脚本或 CI 固化？
本地开发配置和发布配置是否有清楚边界？
新增平台产物时，是否知道应该改配置、资源还是脚本？

这个系列到这里完成了从项目入口、后端服务、数据层、前端组织、runtime、跨平台到发布链路的完整梳理。下一步可以回到自己的 Wails 项目，按每篇文章的检查清单逐层调整，而不是一次性重写整个项目。