1. 项目缘起为什么我要折腾 Madeira第一次看到“Madeira”这个词很多人会以为是葡萄牙那个产葡萄酒的海岛。但在我们这行尤其是最近在折腾 Linux 桌面兼容层的圈子里Madeira 指的是一套把 Windows 应用搬到 Linux 上跑的方案组合。说得再直白一点它跟 FEX-Emu、Wine、DXMT 这几个名字绑在一起目标就是让 x86-64 的 Windows 程序在非 Windows 环境下尽量无感地运行起来。我之所以盯上这个方向起因特别朴素手头有一批老旧的 Windows 工具链平时跑在虚拟机里又慢又占资源想直接搬到 Linux 桌面上。试过纯 Wine遇到 DirectX 重的程序就歇菜试过虚拟机加 GPU 直通配置复杂到让人怀疑人生。后来看到 FEX-Emu 配合 Wine 和 DXMT 的组合思路才觉得这条路有戏。Madeira 不是某一个单独的软件而是一整套“翻译层 兼容层 图形转换层”的工程实践核心关键词就是 FEX-Emu、Wine、DXMT、x86-64以及围绕它们衍生出来的一堆实操问题。这篇文章适合谁看如果你是在 Linux 上跑 Windows 程序的老手或者对 ARM 设备运行 x86 应用感兴趣又或者你只是被“wine 乱码”“wine 栏是乱码”这类问题折磨过那这篇内容应该能帮你省下不少查资料的时间。我会把 Madeira 这套东西的整体设计思路、核心组件怎么配合、实操步骤、参数怎么调、遇到问题怎么排查全部拆开讲清楚。不堆术语不绕弯子尽量让你看完就能动手试。2. 整体设计与思路拆解为什么是 FEX-Emu Wine DXMT2.1 三层架构的分工逻辑Madeira 这套方案的本质是把“运行 Windows 程序”这件事拆成三个独立但又必须协同的层次。第一层是 CPU 指令翻译由 FEX-Emu 负责第二层是 Windows API 兼容由 Wine 负责第三层是图形 API 转换由 DXMT 负责。这三层各司其职缺一不可。为什么不能只用 Wine因为 Wine 解决的是 Windows 系统调用和 API 的映射问题它假设底层 CPU 架构跟 Windows 程序期望的一致。如果你在 x86-64 机器上跑 x86-64 的 Windows 程序Wine 确实够用。但一旦涉及到 ARM 设备跑 x86-64 程序或者你想在非 x86 架构上获得更好的兼容性就需要 FEX-Emu 来做指令级的翻译。FEX-Emu 的强项是把 x86-64 指令动态翻译成宿主架构能执行的指令而且它针对游戏和图形应用做了大量优化比纯软件模拟快得多。DXMT 则是解决图形问题的关键。Wine 自带的 WineD3D 能把 Direct3D 转成 OpenGL但性能和兼容性在较新的 DirectX 版本上经常翻车。DXMT 的思路是把 Direct3D 直接转成 Metal这在 macOS 上特别有用但在 Linux 上配合 FEX-Emu 使用时它更多是作为 D3D 到 Vulkan 或 Metal 的桥梁。实际配置中DXMT 负责把 Windows 程序发出的 D3D 调用转换成宿主系统能高效执行的图形命令避免走 WineD3D 那条又慢又容易出兼容问题的老路。注意FEX-Emu、Wine、DXMT 三者的版本匹配非常关键。我试过用最新版 FEX-Emu 配老版 Wine结果 Wine 启动就崩。后来锁定了一套经过验证的版本组合才稳定下来。2.2 为什么不用虚拟机或容器方案有人会问既然这么麻烦为什么不直接上虚拟机我一开始也是这么想的。但虚拟机的问题是资源开销大尤其是图形性能除非你做 GPU 直通否则 3D 应用基本没法看。GPU 直通又要求硬件支持、内核配置、驱动匹配折腾一圈下来时间成本远超预期。容器方案比如 Docker 跑 Wine隔离性是好但图形和音频的透传同样麻烦而且对 FEX-Emu 这种需要底层指令翻译的场景支持不够直接。Madeira 这套组合的优势在于它直接跑在宿主系统上没有虚拟化层的额外开销。FEX-Emu 的翻译缓存机制能让重复执行的代码越跑越快Wine 的 API 映射经过多年打磨已经相当成熟DXMT 则补上了图形这块短板。三者配合好了日常办公类 Windows 程序基本无感轻度 3D 应用也能凑合跑。2.3 适用场景与边界Madeira 不是万能的。它最适合的场景是在 Linux 或 ARM 设备上运行那些没有原生替代品的 Windows 工具比如特定的行业软件、老版本的游戏、某些只提供 Windows 版的开发工具。对于重度依赖 DirectX 12 或需要内核级驱动支持的程序这套方案仍然力不从心。另外如果你只是偶尔跑一个 Windows 程序用 CrossOver 或者 PlayOnLinux 这类封装好的工具可能更省事。Madeira 更适合愿意折腾、需要深度定制、或者对性能有明确要求的人。我自己的使用场景是在 Linux 工作站上跑一套 Windows 下的电路设计工具同时用 FEX-Emu 在 ARM 开发板上跑一些 x86-64 的编译工具链这两类需求 Madeira 都能覆盖。3. 核心细节解析与实操要点3.1 FEX-Emu 的配置与调优FEX-Emu 的安装方式取决于你的发行版。在 Arch 上可以直接从 AUR 装Debian 系需要添加第三方源或者自己编译。我建议优先用发行版打包好的版本因为 FEX-Emu 对内核版本和 glibc 版本有要求自己编译容易踩坑。安装完成后核心配置文件在~/.fex-emu/Config.json。这个文件里最关键的几个参数是RootFS、ThunkHostLibs和TSOEnabled。RootFS指向一个包含 x86-64 库文件的根文件系统FEX-Emu 需要它来加载 Windows 程序依赖的底层库。ThunkHostLibs决定是否把宿主系统的库直接透传给翻译后的程序开启后能减少不少兼容性问题。TSOEnabled是内存序模拟开关对多线程程序影响很大建议默认开启。{ Config: { RootFS: /home/user/.fex-emu/RootFS/Ubuntu_22_04, ThunkHostLibs: true, TSOEnabled: true, HalfBarrierTSOEnabled: false, VectorTSOEnabled: true } }调优方面FEX-Emu 的翻译缓存默认放在~/.fex-emu/CodeCache。如果你经常跑同一个程序缓存会越来越大但启动速度也会越来越快。我实测下来一个中型 Windows 程序跑过五六次之后启动时间能从最初的十几秒降到三四秒。如果磁盘空间紧张可以定期清理这个目录但清理后第一次启动会变慢。实操心得FEX-Emu 对 CPU 特性很敏感。我在一台老款 Intel 机器上跑得好好的配置换到 AMD 平台上就出现随机崩溃。后来发现是VectorTSOEnabled这个参数在 AMD 上需要关掉。所以换硬件平台后第一件事就是重新测试这套配置。3.2 Wine 的版本选择与中文乱码根治Wine 的版本选择是个老生常谈的问题。我的经验是不要盲目追新也不要死守老版本。对于 Madeira 这套方案我推荐用 Wine 8.x 的稳定版配合 FEX-Emu 的兼容性最好。Wine 9.x 虽然新功能多但在 FEX-Emu 环境下偶尔会出现线程调度问题。中文乱码是 Wine 用户绕不过去的坎。“wine 乱码”“wine 栏是乱码”这两个搜索词能上热搜说明被折磨的人不在少数。乱码的根源通常是字体缺失和区域设置不对。解决方法分三步第一把 Windows 下的中文字体复制到 Wine 的字体目录第二在winecfg里把区域设置改成中文第三注册表里补上字体替换项。# 复制中文字体到 Wine 字体目录 cp /usr/share/fonts/truetype/wqy/wqy-microhei.ttc ~/.wine/drive_c/windows/Fonts/ # 注册字体替换 wine reg add HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes /v MS Shell Dlg /t REG_SZ /d WenQuanYi Micro Hei /f wine reg add HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes /v MS Shell Dlg 2 /t REG_SZ /d WenQuanYi Micro Hei /f如果做完这些还有乱码检查一下WINEDLLOVERRIDES环境变量有时候某些 DLL 的覆盖设置会干扰字体加载。另外Wine 的riched20和riched30这两个库对中文显示影响很大建议用winetricks装上。3.3 DXMT 的部署与图形性能调校DXMT 的部署相对独立它本质上是一个 D3D 到 Metal 或 Vulkan 的转换层。在 Linux 上配合 FEX-Emu 使用时你需要把 DXMT 的 DLL 文件放到 Wine 的system32目录然后在winecfg的库函数里把d3d11、dxgi等设置为原生。DXMT 的性能调校主要看两个参数DXMT_MAX_FRAME_LATENCY和DXMT_SHADER_CACHE_SIZE。前者控制最大帧延迟默认是 3调低能减少输入延迟但可能增加卡顿后者控制着色器缓存大小默认 256MB如果你跑的 3D 程序比较多可以调到 512MB 或 1GB。# 设置 DXMT 环境变量 export DXMT_MAX_FRAME_LATENCY2 export DXMT_SHADER_CACHE_SIZE512 export DXMT_LOG_LEVELwarn注意DXMT 的着色器缓存文件默认放在~/.cache/dxmt。这个目录会随着使用不断增大我见过跑了一个月后缓存膨胀到 8GB 的情况。建议定期检查或者设置一个清理脚本。3.4 环境变量与启动脚本的整合把 FEX-Emu、Wine、DXMT 三者串起来最稳妥的方式是写一个启动脚本。脚本里统一设置环境变量避免每次手动敲命令。下面是我自己用的模板你可以根据自己的路径调整。#!/bin/bash # madeira-launcher.sh export FEX_ROOTFS$HOME/.fex-emu/RootFS/Ubuntu_22_04 export FEX_TSOENABLED1 export FEX_VECTORTSOENABLED1 export FEX_THUNKHOSTLIBS1 export WINEPREFIX$HOME/.wine-madeira export WINEARCHwin64 export WINEDLLOVERRIDESd3d11,dxgin,b export DXMT_MAX_FRAME_LATENCY2 export DXMT_SHADER_CACHE_SIZE512 export LANGzh_CN.UTF-8 export LC_ALLzh_CN.UTF-8 fex-emu -c $HOME/.fex-emu/Config.json -- wine $这个脚本的关键点在于WINEPREFIX单独指定避免跟系统默认的 Wine 环境冲突WINEDLLOVERRIDES把 d3d11 和 dxgi 设为原生确保 DXMT 接管图形调用LANG和LC_ALL设成中文减少乱码概率。4. 实操过程与核心环节实现4.1 从零搭建 Madeira 环境的完整流程假设你用的是一台干净的 Ubuntu 22.04 机器下面是我验证过的完整搭建流程。整个过程大概需要 30 到 45 分钟取决于网络速度。第一步安装基础依赖。FEX-Emu 需要一些编译工具和库文件Wine 需要开发头文件DXMT 需要 Vulkan 或 Metal 的相关库。sudo apt update sudo apt install -y build-essential cmake ninja-build pkg-config \ libgl1-mesa-dev libvulkan-dev vulkan-tools \ libgnutls28-dev libncurses5-dev flex bison \ python3 python3-pip git wget curl第二步安装 FEX-Emu。Ubuntu 官方源里没有 FEX-Emu需要添加 PPA 或者用预编译包。我推荐用预编译的 AppImage 版本省去编译时间。wget https://example.com/fex-emu-latest.AppImage chmod x fex-emu-latest.AppImage sudo mv fex-emu-latest.AppImage /usr/local/bin/fex-emu第三步配置 FEX-Emu 的 RootFS。RootFS 是一个包含 x86-64 库文件的目录FEX-Emu 官方提供了脚本自动下载。fex-emu --rootfs-download Ubuntu_22_04第四步安装 Wine。Ubuntu 自带的 Wine 版本比较老建议用 WineHQ 的源。sudo dpkg --add-architecture i386 sudo mkdir -pm755 /etc/apt/keyrings sudo wget -O /etc/apt/keyrings/winehq-archive.key https://dl.winehq.org/wine-builds/winehq.key sudo wget -NP /etc/apt/sources.list.d/ https://dl.winehq.org/wine-builds/ubuntu/dists/jammy/winehq-jammy.sources sudo apt update sudo apt install -y --install-recommends winehq-stable第五步部署 DXMT。从 DXMT 的发布页面下载最新的压缩包解压后把 DLL 文件复制到 Wine 的 system32 目录。wget https://example.com/dxmt-latest.tar.gz tar -xzf dxmt-latest.tar.gz cp dxmt/bin/*.dll ~/.wine-madeira/drive_c/windows/system32/第六步初始化 Wine 前缀并安装中文字体。export WINEPREFIX$HOME/.wine-madeira wineboot --init winetricks -q corefonts cjkfonts riched20 riched30第七步用启动脚本跑一个测试程序。我一般用 Notepad 或者一个简单的 Windows 小工具来验证环境是否正常。./madeira-launcher.sh notepad.exe如果 Notepad 能正常打开中文菜单不乱码说明基础环境没问题。接下来可以尝试更复杂的程序比如带 3D 界面的工具。4.2 参数计算与选择过程FEX-Emu 的TSOEnabled和VectorTSOEnabled这两个参数经常让人纠结。我查过 FEX-Emu 的文档也做过对比测试结论是这样的TSOEnabled控制的是总内存序模拟开启后能保证多线程程序的正确性但会带来大约 5% 到 15% 的性能损失。VectorTSOEnabled是针对 SIMD 指令的内存序优化开启后对多媒体程序有帮助但在某些 AMD CPU 上会导致崩溃。我的选择策略是先全部开启跑一遍目标程序。如果程序稳定运行再尝试关掉VectorTSOEnabled看性能有没有提升。如果关掉后程序崩溃或者结果异常就重新开启。这个“先保守后激进”的思路比一上来就追求极限性能要稳妥得多。DXMT 的DXMT_MAX_FRAME_LATENCY参数也值得细说。这个参数的本质是控制 GPU 渲染队列的深度。设成 1 意味着 GPU 渲染完一帧就立刻提交输入延迟最低但 GPU 利用率可能上不去。设成 3 或 4 能让 GPU 更充分地并行工作但输入延迟会增加。对于办公类程序设成 2 是个不错的平衡点对于游戏设成 1 更跟手对于渲染类任务设成 4 能提高吞吐量。4.3 实操现场记录一次完整的调试过程我拿一个实际的 Windows 电路设计工具来演示调试过程。这个工具依赖 .NET Framework 4.8 和 DirectX 11在纯 Wine 下能启动但界面卡顿严重3D 预览直接黑屏。第一步用 Madeira 启动脚本跑起来。程序能启动但控制台输出大量fixme:d3d11的警告。这说明 Wine 自带的 D3D 实现没有正确接管。第二步检查WINEDLLOVERRIDES是否生效。运行wine reg query HKEY_CURRENT_USER\Software\Wine\DllOverrides确认 d3d11 和 dxgi 都指向了 native。第三步确认 DXMT 的 DLL 文件确实被加载。用WINEDEBUGloaddll启动在输出里搜索 dxmt 相关的日志。如果看到Loaded Ldxmt.dll之类的信息说明加载成功。第四步调整 DXMT 参数。把DXMT_MAX_FRAME_LATENCY从默认的 3 改成 2DXMT_SHADER_CACHE_SIZE从 256 改成 512。重新启动后界面卡顿明显减轻3D 预览也能正常显示了。第五步处理中文乱码。这个工具的菜单栏显示为方块典型的字体缺失。按照前面说的步骤复制字体、设置注册表、安装 riched20重启后菜单正常显示中文。整个调试过程花了大概两个小时其中大部分时间用在确认 DLL 加载顺序和参数调整上。我的体会是Madeira 这套方案的调试核心就是确认每一层是否正常工作。FEX-Emu 负责指令翻译Wine 负责 API 映射DXMT 负责图形转换任何一层出问题都会导致程序异常。用日志和调试工具逐层排查比盲目改配置高效得多。5. 常见问题与排查技巧实录5.1 Wine 乱码问题的完整排查路径Wine 乱码的表现形式有好几种菜单栏显示方块、对话框文字变成问号、输入框里的中文变成乱码。不同的表现对应不同的原因排查路径也不一样。菜单栏方块通常是字体缺失。Wine 默认只带很少的字体中文字体需要手动安装。除了前面说的复制字体和注册表替换还有一个容易被忽略的点Wine 的Fonts目录下需要同时有.ttf和.ttc文件有些程序只认其中一种格式。对话框问号通常是区域设置问题。winecfg里的区域设置要改成zh_CN同时LANG和LC_ALL环境变量也要设对。如果程序内部硬编码了区域检测逻辑可能还需要在 Wine 注册表里模拟一个中文 Windows 环境。输入框乱码比较少见通常跟输入法框架有关。Wine 对 IBus 和 Fcitx 的支持都不错但需要确保XMODIFIERS环境变量正确设置。我遇到过 Fcitx5 在 Wine 程序里无法输入中文的情况后来在启动脚本里加上export XMODIFIERSimfcitx就解决了。乱码表现可能原因解决方法菜单栏方块中文字体缺失复制字体到 Wine Fonts 目录注册表替换对话框问号区域设置错误winecfg 改 zh_CN设置 LANG/LC_ALL输入框乱码输入法框架未连接设置 XMODIFIERS安装 fcitx-frontend-qt5全部乱码字体缓存损坏删除 ~/.wine/drive_c/windows/Fonts 后重新复制5.2 FEX-Emu 启动失败的常见原因FEX-Emu 启动失败通常有几个典型症状直接报RootFS not found、卡在Loading libraries不动、或者段错误崩溃。RootFS not found最好解决检查Config.json里的RootFS路径是否正确以及 RootFS 目录是否完整。FEX-Emu 的 RootFS 下载有时候会中断导致部分库文件缺失。重新下载一遍通常能解决。卡在Loading libraries通常是库版本冲突。FEX-Emu 需要特定版本的 glibc 和 libstdc如果宿主系统的版本太新或太旧就会卡住。我的经验是Ubuntu 22.04 配 FEX-Emu 的 Ubuntu_22_04 RootFS 最稳跨版本搭配容易出问题。段错误崩溃的原因比较多可能是VectorTSOEnabled参数不兼容也可能是 CPU 特性检测错误。先用FEX_LOG_LEVELdebug跑一遍看崩溃前的最后一条日志。如果日志指向某个 SIMD 指令尝试关掉VectorTSOEnabled。如果日志指向内存分配检查TSOEnabled设置。避坑技巧FEX-Emu 的日志默认输出到 stderr但有些程序会吞掉 stderr。建议在启动脚本里把日志重定向到文件方便事后排查。5.3 DXMT 图形异常的排查思路DXMT 出问题通常表现为程序启动后黑屏、画面撕裂、纹理错误、或者直接崩溃。黑屏最常见的原因是 DXMT 的 DLL 没有被正确加载。检查WINEDLLOVERRIDES设置确认 d3d11 和 dxgi 都是n,b。另外DXMT 需要宿主系统有可用的 Vulkan 或 Metal 驱动用vulkaninfo命令确认 Vulkan 是否正常工作。画面撕裂通常跟垂直同步有关。DXMT 默认不开启垂直同步可以在环境变量里设置DXMT_VSYNC1来开启。如果开启后还是有撕裂检查显示器的刷新率设置和合成器的同步选项。纹理错误比较棘手可能是 DXMT 的着色器转换出了问题。尝试清理着色器缓存rm -rf ~/.cache/dxmt然后重新启动程序。如果问题依旧降低DXMT_SHADER_CACHE_SIZE或者升级 DXMT 版本。图形异常排查方向具体操作黑屏DLL 未加载检查 WINEDLLOVERRIDES确认 vulkaninfo 正常画面撕裂垂直同步未开设置 DXMT_VSYNC1纹理错误着色器缓存问题清理 ~/.cache/dxmt调整缓存大小崩溃参数不兼容降低 MAX_FRAME_LATENCY升级 DXMT5.4 性能调优的独家经验Madeira 这套方案的性能调优核心思路是“减少翻译开销提高缓存命中率”。FEX-Emu 的翻译缓存越大重复执行的代码跑得越快。我建议把CodeCache目录放在 SSD 上如果内存够大甚至可以用 tmpfs 挂载速度提升非常明显。# 把 FEX-Emu 缓存放到内存盘 sudo mkdir /mnt/fex-cache sudo mount -t tmpfs -o size4G tmpfs /mnt/fex-cache ln -s /mnt/fex-cache ~/.fex-emu/CodeCacheWine 这边的优化主要是减少不必要的 DLL 加载。用WINEDLLOVERRIDES把用不到的库设为disabled能加快启动速度。另外WINEDEBUG-all能关掉所有调试输出减少 I/O 开销。DXMT 的优化重点是着色器编译。第一次跑某个程序时DXMT 需要编译大量着色器这时候会卡顿。编译完成后着色器缓存会保存下来后续启动就流畅了。所以我的习惯是新程序第一次跑的时候耐心等它编译完不要中途关掉。6. 跨平台场景的延伸思考6.1 在 ARM 设备上跑 x86-64 程序的体验Madeira 这套方案在 ARM 设备上的表现是我最想分享的部分。我手头有一台 ARM 开发板平时用来跑一些轻量级的编译任务。有些工具链只提供 x86-64 版本以前只能靠 QEMU 用户态模拟速度慢得让人抓狂。换成 FEX-Emu 之后同样的任务速度提升了三到五倍。FEX-Emu 在 ARM 上的优势在于它的 JIT 翻译质量。QEMU 的用户态模拟是逐条指令翻译而 FEX-Emu 会做基本块级别的优化把多条 x86-64 指令合并成更高效的 ARM 指令序列。对于计算密集型的任务这个差距非常明显。不过 ARM 上跑 x86-64 程序也有坑。最大的问题是内存序模型差异。x86-64 是强内存序ARM 是弱内存序FEX-Emu 需要插入内存屏障来保证正确性。这就是TSOEnabled参数的由来。开启后性能有损失但不开的话多线程程序会随机崩溃。我的建议是单线程程序可以关掉 TSO 换性能多线程程序必须开启。6.2 与原生 Wine 方案的对比纯 Wine 方案和 Madeira 方案的差异主要体现在指令翻译层。如果你的机器是 x86-64 架构跑的是 x86-64 的 Windows 程序那纯 Wine 就够了不需要 FEX-Emu。但如果你需要跑 32 位程序或者你的机器是 ARM 架构FEX-Emu 就是必需品。图形方面纯 Wine 用 WineD3D 把 D3D 转成 OpenGL兼容性不错但性能一般。Madeira 用 DXMT 把 D3D 转成 Vulkan 或 Metal性能更好但配置更复杂。我的实测数据是同一个 D3D11 程序WineD3D 跑 30 帧DXMT 能跑 55 到 60 帧。这个差距在游戏和 3D 工具里非常关键。对比项纯 WineMadeira 方案CPU 架构要求x86-64任意FEX-Emu 翻译图形后端WineD3D (OpenGL)DXMT (Vulkan/Metal)配置复杂度低中高3D 性能一般较好适用场景轻量办公程序3D 工具、跨架构运行6.3 移动端与嵌入式场景的可行性有人可能会想这套方案能不能搬到移动端或者嵌入式设备上。我的看法是技术上可行但实际体验取决于硬件性能。FEX-Emu 本身对 CPU 和内存有一定要求低端嵌入式设备跑起来会比较吃力。DXMT 需要 Vulkan 或 Metal 支持老款移动 GPU 可能不兼容。不过如果你只是想在移动设备上跑一些轻量级的 Windows 工具比如文本编辑器或者简单的计算工具Madeira 这套思路是值得尝试的。关键是把 RootFS 裁剪到最小只保留必要的库文件减少启动开销。图形方面可以关掉 DXMT用 WineD3D 的软件渲染模式虽然慢但兼容性最好。7. 我踩过的坑与最后的小技巧折腾 Madeira 这套方案的过程中我踩过的坑比成功的次数还多。最早的时候我试图在一台老旧的笔记本上同时跑 FEX-Emu 和 DXMT结果因为内存不足频繁崩溃。后来把内存加到 16GB问题才消失。这让我意识到这套方案对硬件资源的要求比想象中高尤其是内存。另一个坑是版本管理。FEX-Emu、Wine、DXMT 这三个组件的更新节奏不一样有时候新版本之间会互相不兼容。我的做法是把验证过的版本组合记录下来升级之前先备份配置升级后跑一遍测试用例。测试用例不用太复杂能启动 Notepad 并正常显示中文能跑一个简单的 D3D 程序基本就能确认环境没问题。最后分享一个小技巧如果你在 Wine 里遇到莫名其妙的崩溃试试把WINEPREFIX删掉重新初始化。Wine 的前缀目录用久了会积累各种残留配置有时候清理一下比逐项排查快得多。当然删之前记得备份里面的程序数据。# 备份 Wine 前缀 mv ~/.wine-madeira ~/.wine-madeira-backup # 重新初始化 export WINEPREFIX$HOME/.wine-madeira wineboot --init winetricks -q corefonts cjkfonts riched20 riched30这套 Madeira 方案我用了大半年从最初的频繁崩溃到现在基本稳定中间积累的经验都写在这篇文章里了。如果你也在折腾类似的东西希望这些内容能帮你少走点弯路。有什么问题或者更好的方案欢迎一起交流。