umu、Wine 与 Proton：看懂兼容层，再选 Bottles 运行器

在 Bottles 里看到 umu 游戏入口，再打开运行器列表，Wine、Proton、Soda、ProtoSoda、Caffe、GE、Lutris 等名字很容易挤成一团。究竟应该换启动器，还是换运行器？普通软件与游戏能否共用同一套环境？

理解这套生态，可以沿着一条运行链看：Wine 提供 Windows 兼容能力，Proton 将它整合成游戏方案，umu 在 Steam 客户端之外组织 Proton 的运行环境，Bottles、Lutris、Heroic 则负责安装和管理。弄清每个名字负责哪一步，再挑工具，会比按名字排兼容性名次省事得多。

先拆开兼容层、套件、运行环境与管理器#

层级	代表项目	负责什么
Windows 兼容层	Wine	实现 Windows 应用需要的接口与行为，使程序在 Linux 等系统上运行。
面向游戏的兼容套件	Proton、GE-Proton	以 Wine 为核心，集成图形转换组件、游戏补丁、运行库与启动逻辑。
启动与运行环境协调	umu-launcher	在 Steam 客户端之外准备 Proton 所需的 Linux 运行环境，并组织启动。
图形管理前端	Bottles、Lutris、Heroic	管理安装、程序入口、前缀、版本、依赖、配置和游戏库，调用兼容工具。

Wine 做的是 Windows API 兼容，并不需要先安装一套 Windows 虚拟机。Proton 包含 Wine，却也包含围绕游戏运行组织起来的其他组件；单独拿到一个 Wine 可执行文件，不能代表拿到了完整的 Proton 工作流。Proton 官方说明将它定位为通过 Steam 客户端运行 Windows 游戏的工具。

图形转换又是其中一个具体环节。DXVK 把 Direct3D 8/9/10/11 转为 Vulkan，VKD3D-Proton 负责 Direct3D 12。这些组件也能用于其他 Wine 运行方案，所以在 Bottles 中开启 DXVK，并不能据此认定正在使用 Proton。

Wine:
Bottles / Lutris → Wine runner + components → Windows application

Steam + Proton:
Steam → Steam Linux Runtime → Proton → Windows game

umu + Proton:
Bottles / Lutris / Heroic → umu + runtime → Proton → Windows game

最后一条路线，把原本由 Steam 组织的一部分运行基础设施提供给其他启动器。用户看到的管理界面不同，下面可以使用相近的 Proton 套件与同一套 umu 基础设施。

umu 解决的是怎样使用 Proton#

Proton 需要它预期的 Linux 环境

Proton 里面也有 Wine，直接调用其中的 wine 运行 .exe，看起来像一条捷径。但这样可能绕开 Proton 的启动逻辑和容器运行环境，转而加载发行版自己的共享库。库版本恰好匹配时也许能运行，对不上时就容易产生难以解释的故障。

umu-launcher 负责准备运行环境、设置启动参数并调用选定的 Proton；它可以在没有安装 Steam 客户端的情况下工作。GE-Proton 的维护说明也明确将 umu 列为 Steam 外使用 GE-Proton 的受支持方式。

这里的 Steam Linux Runtime 是 Linux 侧的运行库与容器环境。它让跨发行版的库版本更可预测，和 Windows 系统镜像是两回事。umu 提供这部分启动基础设施，并没有复制 Steam 的游戏商店、账号、下载管理或完整客户端功能。

游戏专属修复可以在不同启动器之间复用

有些游戏需要特定依赖、DLL 覆盖或启动设置，单纯更新 Wine 未必能解决。umu 生态的游戏标识数据库与 protonfixes，使启动器能够传入游戏及商店信息，再由带有修复机制的兼容套件应用相应规则。一部分适配因此可以跨启动器共享。

游戏数据库承担识别与匹配的作用。没有条目的程序仍可尝试运行；没有识别出游戏，或者缺少现成规则时，就没有对应的专属修复。把 umu 理解为统一运行环境与修复入口，更符合它的实际作用；是否改善帧率，仍需要针对具体游戏测量。

Bottles 加入 umu 后，管理器怎样选#

Bottles 66 将 umu 接入 Library，并引入 ProtoSoda。Bottles 保存游戏入口、前缀、兼容工具、依赖与设置，umu 准备 Proton 的运行环境。因此，这项变化扩展了 Bottles 的游戏工作流，不能只理解为下拉菜单中新增了一个 Wine 版本。

Soda 属于 Bottles 的 Wine 运行器路线；ProtoSoda 则面向 Proton／umu 的使用方式。两者的职责也需要分清：ProtoSoda 是实际运行游戏的兼容套件，umu 负责将这套工具放进相应环境启动。

管理工具	主要侧重点	选择时看什么
Bottles	Windows 软件环境，以及 umu 游戏工作流。	把软件的依赖、设置和入口放在一起管理；新增独立游戏也可以直接尝试。
Lutris	跨来源、跨运行方式的游戏管理。	Wine／Proton、模拟器及其他运行器，以及 Battle.net、EA App、Ubisoft Connect 等客户端流程。
Heroic	Epic、GOG、Amazon 游戏库。	商店登录、下载、更新、云存档与游戏管理；运行游戏时调用 Wine／Proton。
PortProton	预先整合 Windows 游戏的运行工具。	Wine／Proton 派生版本、运行环境、脚本和配置，减少手动组合。
CrossOver	商业化 Windows 软件兼容产品。	CodeWeavers 的兼容开发、产品集成与技术支持，大量开发工作会回到 Wine 上游。
PlayOnLinux	多个 Wine 版本与独立软件环境。	为不同程序选择相应 Wine 版本、安装流程与配置。

Lutris 已接入通过 umu 启动 GE-Proton 的路线；Heroic 也将 umu 用于 GE-Proton。Bottles 与 Lutris 因此完全可能共用运行底座，区别更多体现为安装流程、依赖处理、参数传递与管理方式。

共用底座并不意味着所有安装脚本和配置也自动互通。选择前端时，先看自己的游戏来源、客户端安装流程，以及是否希望集中管理软件环境。PortProton、CrossOver 和 PlayOnLinux 同样是在 Wine 生态上组织不同的使用体验。

运行器名字代表哪些取舍#

Bottles 列表里的 Soda、Caffe、Kron4ek 等属于 Runner，也就是运行器。列表里的 Lutris 通常指 Lutris 提供的 Wine 构建，需要和 Lutris 图形管理软件区分开。

这些构建主要在补丁选择、更新节奏、打包方式和目标应用上作取舍。Wine Staging 包含尚未进入 Wine 主开发分支的修复与实验功能；GE-Proton 为 Proton 加入额外补丁、媒体处理和游戏修复。多带补丁可能解决某个问题，也可能产生新的回归，不能按名字排出一条通用的兼容性升级阶梯。

Wine-GE 与 GE-Proton 是不同项目。过去常见的“Steam 内用 GE-Proton、Steam 外用 Wine-GE”分工已经发生变化：Wine-GE 于 2025 年 7 月 11 日归档，README 将 umu 列为后继路线；现在可以在 Steam 外通过 umu 使用 GE-Proton。保留一个旧程序确实依赖的 Wine-GE 版本仍有意义，新环境则优先考虑当前受支持的方案。

Winetricks 帮助安装组件与应用兼容设置；ProtonUp-Qt 安装和管理兼容工具版本。它们解决运行链中的辅助事务，不承担整套 Windows API 兼容或完整游戏库管理。

Soda、ProtoSoda 和其他运行器怎么选#

对于新建的 Bottles 环境，可以先收敛为：普通 Windows 软件用稳定版 Soda，通过 umu 管理的游戏先用 ProtoSoda，再将 GE-Proton 留作主要备用。这是一套减少配置变量的起始顺序。某个程序已经在其他运行器上稳定工作，可以继续保留原来的选择。

运行器	定位	建议用法
Soda	Bottles 自家维护、包含兼容补丁的 Wine 构建。	普通软件的默认起点，优先稳定版；已经正常运行的游戏也可以继续使用。
ProtoSoda	将 Soda 的 Wine 核心与 Proton 的启动、目录结构和组件结合，面向 umu。	在 Bottles 中新建 umu 游戏时优先尝试。
GE-Proton／Proton-GE	含额外媒体补丁、游戏专属修复等的社区 Proton 构建。	游戏的主要备用；具体修复明确提到目标游戏时可以直接优先，Steam 外配合 umu。
Proton-CachyOS	包含前沿特性、社区修改与额外工具的 Proton 分支。	有明确特性需求或实测收益再采用，同时核对所选构建的硬件要求。
Kron4ek	提供 Vanilla、Staging、Staging-TkG 等不同 Wine 构建的来源。	普通软件排障时，用来尝试更新的上游 Wine 或不同补丁组合。
Caffe	Bottles 的另一条 Wine 补丁构建路线。	按具体软件的兼容结果使用；组件目录仍保留 Caffe 10.0，不能仅凭较少被提及就判断已停更。
Vaniglia	Bottles 偏向上游、补丁较少的 Wine 路线，旧文档仍描述过 Staging 补丁。	作为兼容性对照，核对具体版本及补丁；名称不能直接等同于完全原版 Wine。
Wine-GE	过去面向非 Steam 游戏的 Wine 构建，已停止维护。	新环境不优先；旧程序确实依赖某个版本时保留。
Lutris／Lutris-Wine	Lutris 提供的 Wine 构建，Bottles 的这组目录含历史版本。	目录仍含 lutris-7.2-2 等历史版本；用于复现旧方案或保留已工作环境，先核对年代。

Bottles 的运行器文档保留了 Caffe、Vaniglia 等路线的介绍，其中 Vaniglia 明确提到 Wine Staging 补丁。这份文档带有旧版本语境，实际可安装版本应结合组件目录和运行器自己的发行说明核对。

选择 Soda 加 ProtoSoda，主要是方便沿用 Bottles 已组织好的两种工作流。普通软件使用传统 Wine 瓶子，umu 游戏使用 Proton 套件，并不意味着两者之间存在“软件只能用 Soda、游戏只能用 ProtoSoda”的限制。

ProtoSoda 也会组合其他项目的成果。例如 ProtoSoda 11.0-2 的发行说明明确写着：Wine 核心来自 Soda 11.0-7，启动器、运行库、DXVK、VKD3D 与 protonfixes 更新到 GE-Proton11-6 对应版本。它并非和 GE-Proton 完全独立的两套东西；判断差别时，应查看具体版本的组成。某款游戏已经在 GE-Proton 上运行良好，就继续使用它，无需为了统一列表而切回 ProtoSoda。

遇到问题时，按用途缩小选择范围#

普通 Windows 软件

先使用稳定版 Soda。如果失败，查软件的已知要求与日志，再有针对性地尝试 Caffe 或 Kron4ek。需要某个 Wine 修复时选择包含它的版本，比把所有运行器依次试一遍更有依据。

Kron4ek 尤其要看完整后缀：vanilla 接近上游原版，staging 加入 Staging 补丁，staging-tkg 再采用其他补丁组合。它们体现的是构建差异，不能当成低配、中配、高配。程序对某个补丁有依赖或回归，才是选择相应构建的理由。

通过 umu 管理的游戏

先尝试 ProtoSoda 加 umu，出现兼容问题时再尝试近期 GE-Proton 加 umu。如果 GE 的发布记录明确修复了目标游戏，可以直接从 GE 开始。Proton-CachyOS 留给已知特性需求或具体对比测试；“优化版”的名称本身不能保证当前机器和当前游戏更快。

版本也需要单独判断。截至 2026 年 10 月 14 日，Soda 11.0-10 属于稳定发布，而 11.0-30-experimental 明确标为预发布，并声明不替代当前稳定版。带有 experimental 的更大数字不能自动替代稳定发布。记录完整版本、发布渠道与组件组成，才能判断后来究竟改了什么。具体版本会继续更新，下载前以对应发布页为准。

重要软件先保留关闭状态下的完整前缀备份，使用测试瓶子尝试新运行器；一次只调整一个变量。若同时更换运行器、图形组件和一批 DLL 设置，就很难定位改善或故障来自哪一步。清理旧运行器前，也先确认没有现有瓶子继续依赖它。

落实到 Steam、客户端游戏与 NixOS#

Steam 管 Steam 游戏，Lutris 管其他游戏，Bottles 管其他 Windows 软件，仍是一种方便的日常分工。Bottles 新增 umu 后，这种分工更多是管理偏好，下面的兼容能力可以重叠，不必迁移已经工作的环境。

Steam 游戏继续优先交给 Steam，让客户端协调官方 Proton 和运行环境。Battle.net、炉石等带客户端的场景，可以继续保留已经配置好的 Lutris 路线；选择依据是客户端安装和管理流程，具体兼容性仍取决于当时的客户端、游戏与运行器版本。普通软件放在 Bottles，新增独立 Windows 游戏也可以直接尝试 Bottles 的 umu 工作流。

对于 NixOS，可预测的 Linux 运行环境尤其值得重视。umu 官方文档已有 nixpkgs 中 pkgs.umu-launcher 的使用说明，因此单纯为了使用 umu，无需额外套一层 Arch Distrobox。实际安装仍应采用适配好的发行包，同时核对图形驱动、运行环境与程序行为，避免任意拆用 Proton 内部的 Wine。

比较性能时，应对齐游戏版本、兼容工具、图形组件、启动设置和运行环境。只凭 Bottles 或 Lutris 的界面名称，很难判断哪一个会明显更快；差异出现后，先检查它们实际调用的组件与参数。Valve 的 Proton 文档也说明了反作弊支持的条件：游戏未支持的内核级反作弊，不会因为更换管理器或接入 umu 就自动可用。

日常选择可以保持简单：保留稳定版 Soda 与 ProtoSoda，游戏需要时加入 GE-Proton，Kron4ek 作为普通软件的排障选项，其他运行器按具体需求使用。把已经正常工作的组合留下，等到明确的兼容问题出现，再调整真正相关的那一层。