装机从开七八个终端到一次全部升级，UniGetUI 把 WinGet、Scoop 和 Chocolatey 收进同一个窗口

给 Windows 重装系统之后装软件，是很多开发者的固定折磨：WinGet 装开发工具，Scoop 管命令行套件，Chocolatey 处理一些老软件，再加上 pip 和 npm 的全局包，四五个终端窗口来回切。更麻烦的是更新：没有一个地方能统一检查升级，只能逐个跑命令，漏掉几个版本是常事。

公众号「GitCube」推荐的开源项目 UniGetUI（原名 WingetUI）就是为这件事准备的。项目的自我描述很有幽默感：“包管理器的包管理器”。它是一个图形界面，把 WinGet、Scoop、Chocolatey、pip、npm、.NET Tool 和 PowerShell Gallery 这些命令行包管理器统一到一个窗口里。源文统计它在 GitHub 上已有 2.1 万多 Star。

本文梳理 UniGetUI 的核心能力和使用要点，再用一个 Python 脚本模拟这类“统一前端”背后要解决的几个工程问题。

一、先说一个变化：项目已移交 Devolutions 维护

源文没有提到一点：UniGetUI 的作者 Martí Climent 已经把项目交给 Devolutions 公司负责开发和维护，作者原来的个人网站页面也明确写着“这里不再是 UniGetUI 的家”，官方网站迁到了 Devolutions 的站点（devolutions.net/unigetui）。

这对使用者意味着两件事：项目背后有了一家商业公司持续投入，长期维护更有保障；同时，下载和查阅文档时要以新的官方渠道为准，避免从过期的镜像下载安装包。

二、它解决了什么问题

UniGetUI 的统一管理流程

UniGetUI 本身并不负责安装软件，真正干活的仍然是底层各个包管理器，它做的是统一的“前台”：

统一的已安装列表：打开后会扫描出所有已安装的软件，不管是通过哪个包管理器装的，全部列在一起；
统一搜索：输入软件名，多个源的结果同时返回，选一个装就行；安装前可以查看包的详细信息，比如发布者、下载地址和大小；
统一更新：有新版本的软件集中显示，支持批量勾选、一键升级；也可以设置为自动更新，或者只在有更新时通知；
按包精细控制：可以对单个包忽略更新、跳过某个特定版本；可以选择安装旧版本、强制安装 32 位版本，自定义安装参数，这些选项会被记住，后续更新时继续生效；
系统集成：托盘图标显示可用更新，还支持 Windows 小组件和 Dev Home 面板。

这套功能可以概括为下面的流程：

Mermaid Diagram

三、最实用的功能：导出与导入软件清单

源文作者第一次用到时觉得“挺惊喜”的功能，是导出软件包列表：把当前机器上的软件连同版本号、安装参数和来源渠道导出成一个文件，换新机器时导入，泡杯咖啡回来，环境基本就还原了。官方的功能描述也强调了这一点：既可以导出自定义的软件清单（带上预先指定的安装参数）给其他机器使用，也可以把全部软件备份到本地文件，迁移新机时几秒钟就能恢复。

值得一提的是，各个包管理器自己也有类似能力，只是各管各的：

winget export -o winget-packages.json
winget import -i winget-packages.json

scoop export > scoop-packages.json
scoop import scoop-packages.json

UniGetUI 的价值在于把它们合到一份清单里：WinGet 的开发工具、Scoop 的命令行套件、npm 的全局工具，一次导出、一次导入。对经常重装系统或需要管理多台机器的人来说，这能省下大量重复劳动。

四、安装方式

源文给出了三种安装方式，选自己顺手的即可：

1. 在微软商店搜索 UniGetUI 安装；

2. 用 WinGet 安装，源文给出的命令是：

winget install --exact --id MartiCliment.UniGetUI --source winget

3. 从 GitHub 发布页下载安装包。

由于项目已经移交维护，包的标识未来可能调整。安装前可以先执行 winget search UniGetUI 确认当前的包 ID 和发布者。安装后 UniGetUI 支持自动更新。

兼容性方面，官方说明正式支持 Windows 10 x64（10.0.19041 及以上）和 Windows 11 x64；Windows 11 arm64 可以通过 x64 仿真运行；Windows Server 能用，但 WinGet 可能不太稳定，Chocolatey 也可能需要手动安装 .NET Framework 4.8，这些都不在官方支持范围内。

五、动手实验：一个“统一前端”要解决哪些工程问题

UniGetUI 是 Windows 图形程序，没法在 Linux 实验环境里运行。但它背后的核心抽象很值得拆开看：怎样把几种格式完全不同的命令行输出，合成一份统一的、可操作的列表？

配套脚本 practice/demo_unified_packages.py 只依赖 Python 标准库，用各工具真实的输出格式作为样例，模拟了这个过程：

WinGet 的 winget upgrade 输出的是定宽表格，要按表头中各列的起始位置切分，而不能按空格切分，因为软件名本身就带空格；
Chocolatey 的 choco outdated -r 输出的是竖线分隔的机器可读格式，最后一列表示是否锁定了版本；
pip 的 pip list --outdated --format=json 和 npm 的 npm outdated -g --json 输出 JSON，但字段名各不相同（latest_version 和 latest）。

解析之后，所有包被归一成同一个数据结构，再依次做版本比较、应用忽略和跳过规则、导出清单、在新机器上按来源生成安装命令。运行结果：

$ python3 demo_unified_packages.py
[1] 4 种输出格式统一解析出 9 个包：
    winget Microsoft.VisualStudioCode     1.104.0 → 1.105.1
    winget 7zip.7zip                        24.08 → 25.01
    winget Git.Git                         2.50.1 → 2.51.0
    choco  nodejs-lts                     20.18.0 → 22.20.0
    choco  python312                       3.12.6 → 3.12.10
    pip    requests                        2.32.3 → 2.32.5
    pip    black                          24.10.0 → 25.9.0
    npm    pnpm                            9.15.0 → 10.18.2
    npm    typescript                       5.9.2 → 5.9.3
[2] 版本比较：字符串比较 vs 分段数字比较
    2.50.1 < 2.51.0？ 字符串：True   分段数字：True
    3.12.6 < 3.12.10？ 字符串：False  分段数字：True
    9.15.0 < 10.18.2？ 字符串：False  分段数字：True
[3] 应用忽略与跳过规则后的更新队列：
    更新 Microsoft.VisualStudioCode
    更新 7zip.7zip
    保留 Git.Git                      跳过 2.51.0
    更新 nodejs-lts
    保留 python312                    已锁定版本
    更新 requests
    保留 black                        已忽略
    更新 pnpm
    更新 typescript
[4] 导出清单 8 项，849 字节，首项：{"id": "Microsoft.VisualStudioCode", "source": "winget", "version": "1.104.0", "options": {}}
[5] 在新机器导入清单，按来源生成安装命令：
    winget install --exact --id Microsoft.VisualStudioCode --version 1.104.0 --source winget
    winget install --exact --id 7zip.7zip --version 24.08 --source winget
    winget install --exact --id Git.Git --version 2.50.1 --source winget
    choco install nodejs-lts --version 20.18.0 -y
    choco install python312 --version 3.12.6 -y
    pip install requests==2.32.3
    npm install -g pnpm@9.15.0
    npm install -g typescript@5.9.2
全部校验通过

有两处结果值得注意：

第 2 步：按字符串比较，3.12.6 会被认为比 3.12.10 新，9.15.0 会被认为比 10.18.2 新，这正是“漏掉更新”或“误报降级”的常见来源。版本号必须按段拆开、按数字比较；
第 4 步：导出的是当前已安装的版本，而不是可升级到的版本。被锁定的 python312 和跳过了新版本的 Git，在新机器上还原的仍然是原来的版本，这样“导出清单”才是对当前环境的忠实快照。被忽略更新的 black 则按规则从清单中排除。

六、使用时的注意事项

底层问题仍需到底层解决：源文也提到，UniGetUI 只是界面，WinGet 或 Scoop 自身出问题时，它也帮不上忙，得到对应的包管理器排查。遇到安装失败，先在终端里手动执行同样的命令，看原始报错；
资源占用：UniGetUI 基于 .NET 开发，内存占用不算轻量，低配机器上能感觉到；
软件来源的可信度：WinGet 和 Chocolatey 的社区仓库都有审核机制，但审核的严格程度不同。安装前用 UniGetUI 的详情页确认发布者和下载地址，对来路不明的包保持警惕；
批量升级前先看清单：一键全部升级很爽，但 Node.js、Python 这类运行时跨大版本升级可能影响现有项目。对这类包，可以像演示脚本中那样锁定版本或跳过特定版本；
提权操作：部分安装程序需要管理员权限，批量操作时会弹出多次 UAC 确认，可以在设置中调整相关行为，但不要为了省事长期以管理员身份运行所有安装。

七、总结

WinGet、Scoop、Chocolatey 单独拿出来都不新鲜，UniGetUI 的价值在于把它们装进同一个窗口：一份已安装列表、一个搜索框、一个更新按钮、一份可以带到新机器上的清单。源文作者的评价是，这种“整合即创新”的思路在开源社区很常见，但真正做好的不多，UniGetUI 算是其中比较扎实的一个。

如果你管理着不止一台 Windows 开发机，或者每年要重装几次系统，花十分钟把现有环境导出一份清单，下次装机时就能省下大半天。

项目地址：https://github.com/marticliment/UniGetUI